To avoid the vulnerability, each request must be authenticated in some way and the authentication verified. This amounts to supplying a session cookie, whether you do it in the GET URL, e.g.
domain.com/details/1234
where 1234 is your user (and also his session), or within a POST or JSON request.
In the above, you have the authentication, but it is not verified. Anyone can claim to be user 1234.
Either you add a separate cookie, which still exposes the user id:
domain.com/details/1234:db81390fb2befd1dd839c37ab39d699cddb8d65b
or you pack everything inside the cookie:
domain.com/db81390fb2befd1dd839c37ab39d699cddb8d65b/details
The above has the advantage that you can internally rewrite the request after checking it to
domain.com/details/1234
so that the application "behind" the security layer can remain unchanged.
The security layer will extract the cookie, verify it is valid (it can contain its own cryptographic signature and a nonce, to avoid replay attacks), and from the cookie-associated session recover the user id 1234 and pass it along.
When authenticating for the first time, a new session is generated and associated to the cookie. If you use a "large enough" cookie, you can add randomization to it:
1. The mobile app requests the user details:
domain.com/db81390fb2befd1dd839c37ab39d699cddb8d65b/details
2. The server destroys cookie db813... and replies with JSON:
{
'cookie': '926c8a7699c367d3da9370f433189a20b06f8f3d',
...other details...
}
3. The next request will have to contain cookie 926c8... to be accepted.
In the above scenario, you can further tighten security by adding state awareness to the application. For example when you receive the above JSON the mobile app is in "Display Details" status, and from that status, only a very limited number of transitions are allowed. You might not be able to transition in one step from there to the "Change User Password" screen, for example.
Which means that if an attacker is able to intercept the JSON request, and attempts to use it to access the Change Password function:
domain.com/926c8a7699c367d3da9370f433189a20b06f8f3d/newpassword
it can be identified as an illegal transition. The newpassword method will "see" that the previous state was not "User Profile" or "Security Menu" but "Display Details", which is not germane, and the connection can then be aborted.
The attacker would then have to first transition from Details to Main Menu and from there to User Profile, thus regenerating the cookie once or twice and thereby cutting out the legitimate user. The legitimate user app does not know that its state is now out of sync and might attempt to use the cookie it has. Such cookie reuse can be detected and taken as evidence that a cookie has been intentionally intercepted. You will not be able to reliably tell who is the attacker and who's the victim, but you can abort both connections.
