Recently I attended a workshop were the presenter explained securing rest APIs.

One of the things he recommended to avoid man in the middle attacks was to not send IDs in the URLs (i.e. not sending the IDs as path parameters For e.g. Don't do this : GET /orders/{order-id}). This way a malicious hacker will not be able to change the IDs in flight and direct the request to an incorrect resource in the back-end. Better approach would be to put ids in the body and sending the body as the part of the payload of a token. If some one tampers with the token then the signature in the token wont match with the modified content in the payload.

Is this the right approach or the best approach?

1 Answer 1


... to avoid man in the middle attacks was to not send IDs in the URLs (i.e. not sending the IDs as path parameter ex. Don't do this : GET /orders/{order-id})

A man in the middle can both manipulate the request header (containing the target URL) and the request body too, so the "protection" to move important information into the body will not help.

... Better approach would be to use something like tokens and IDs in the body.

I'm not sure what exactly you mean with this. But if for example the order-id given by the server should be save against manipulation by a man in the middle attacker then protecting it with a signature (token) based on the order-id, the current user session and some server side secret would work. It would be irrelevant if this is used in the URL or the request body though.

Anyway, trying to protect against an active man in the middle by somehow protecting fields is not sufficient since it only protects information provided and protected by the server but not by the user (i.e. where to ship stuff etc). Protection against man in the middle attacks should be done with encryption by HTTPS instead.

Protecting server-provided information (like order-id) with signatures is instead a way to protect against attacks where some attacker tries to access data from other users. This is not specific for man in the middle attacks though.

  • I have updated the question to convey what I was asking correctly. Dec 17, 2019 at 6:50
  • 1
    @humbleCoder: Again, a man in the middle can easily modify the body of the request too. Simply putting data into the body instead of the URL will not protect them. Signatures (tokens) will protect them instead but it does not matter if parameters and signatures are in the body or the URL for this. Dec 17, 2019 at 6:55
  • For man in the middle its clear now to me as per your answer that we have to use HTTPS to encrypt end to end communication. However someone can still modify the requested URL right (In my understanding HTTPS does not encrypt the URL we are trying to hit) So I fail to understand why moving parameters (order_id) to the body and securing them with tokens and signatures will not protect against someone changing the ids and redirecting the request to a unwanted resource. Dec 17, 2019 at 8:05
  • 1
    @humbleCoder: "In my understanding HTTPS does not encrypt the URL we are trying to hit" - Your understanding is wrong, i.e. HTTPS encrypts the URL including path, parameters etc. It does have the domain name part of the URL in clear in the TLS handshake but even this is protected against manipulation. See also Are GET parameters secure over https?. Dec 17, 2019 at 8:33
  • Ohhhh..now I get it..thanks..that was a big gap in my knowledge!! Dec 17, 2019 at 8:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .