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?

2 Answers 2


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 [...]

  • 1
    This is no longer true with (draft) TLS 1.3 if 0-RTT tickets are enabled. Also—though not strictly within scope for the question—a replay attack can still be mounted even with current TLS versions if using a web browser. Jul 28, 2018 at 14:37

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.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.