Take the 2-minute tour ×

I am exposing a few REST methods on a server for an mobile app.

I would like to avoid that users can sniff how HTTP methods are built (from the mobile app) and then send them again to the server. Example :

  • The mobile app send a request
  • The user uses a proxy and can check what's going on on the network
  • The user sees and save the request that the mobile just sent
  • => Now I don't want the user to be able to send over manually that request

Is it enough to secure the server over HTTPS?

share|improve this question
add comment

2 Answers

up vote 3 down vote accepted

HTTPS can be enough to secure the server from replay attacks (the same message being sent twice) if the server is configured to only allow the TLS protocol as per rfc2246 section F.2.

Outgoing data is protected with a MAC before transmission. To prevent message replay or modification attacks, the MAC is computed from the MAC secret, the sequence number [...]

share|improve this answer
add comment

HTTPS simply means that the data being transported is encrypted so that only the client and server can decrypt it (in an ideal world, not talking about MITM attacks etc).

As such, nothing in the protocol will stop replay attacks from happening.

You will need to build in some sort of replay attack avoidance mechanism (something like expiring tokens, or tokens that invalidate after the process has finished) to ensure that your application is not vulnerable to replay attacks. This mechanism can be used with normal HTTP.

share|improve this answer
This answers seems to suggest the opposite: stackoverflow.com/questions/2769992/… Any idea why the difference? –  Brian Armstrong Aug 8 '12 at 23:14
add comment

Your Answer


