Protect against replay attacks: practical layers for APIs

Use layered freshness checks so a recorded valid request cannot be accepted again: require unique nonces or request IDs and validate them server-side, enforce tight timestamp windows, use short-lived or one-time tokens, sign requests, and combine these with TLS. At scale, add sequence-number windows or a replay cache to reject duplicates.

What a replay attack is and why it matters

A replay attack is when an attacker captures a valid message and later resends it to get the same effect again, such as repeating a transaction. A practical prevention is to include a single-use identifier (for example, a nonce) that the receiver verifies and refuses to accept again https://developer.mozilla.org/en-US/docs/Glossary/Replay_attack.

Core protections to add now

Nonces and timestamps (freshness at the application layer)

Require each request to carry a unique, unpredictable nonce or request ID and keep a short-lived record of recently seen values so duplicates are rejected. Alternatively, add a timestamp and enforce a narrow acceptance window with a small allowance for clock skew. Both techniques are standard anti-replay methods https://dti-techs.gitbook.io/practical-foundations-in-cybersecurity/5.-cryptography-and-wireless-security/replay-attacks-and-anti-replay-methods and align with the nonce guidance above https://developer.mozilla.org/en-US/docs/Glossary/Replay_attack.

Short-lived and single-use tokens

Make access tokens expire quickly so a captured token has limited value. For sensitive actions, prefer one-time tokens tied to a specific request context and reject reuse. Combine tokens with a nonce or request ID so even a valid, unexpired token cannot be replayed for the same action https://dti-techs.gitbook.io/practical-foundations-in-cybersecurity/5.-cryptography-and-wireless-security/replay-attacks-and-anti-replay-methods. For safe client retries that don’t duplicate work, pair this with idempotency keys: Idempotency keys: safe retries without duplicate actions.

Sign requests

Protect integrity and authenticity by signing a canonical set of fields or the entire payload with an HMAC or MAC. Include the nonce or timestamp inside what is signed so attackers cannot alter freshness data without invalidating the signature https://dti-techs.gitbook.io/practical-foundations-in-cybersecurity/5.-cryptography-and-wireless-security/replay-attacks-and-anti-replay-methods.

Protocol-level measures and scalable duplicate detection

Sequence numbers and sliding anti-replay windows

For ordered messaging, attach a monotonic sequence number to each message. The receiver tracks a sliding window of acceptable values and discards numbers outside the window or already seen. Window sizing balances tolerance for reordering against memory and replay surface https://dti-techs.gitbook.io/practical-foundations-in-cybersecurity/5.-cryptography-and-wireless-security/replay-attacks-and-anti-replay-methods.

Replay caches and Bloom filters

High-throughput services can maintain a replay cache of recently seen request IDs. Space-efficient Bloom filters are a practical option: they answer “probably seen” or “definitely not seen,” trading small memory for a nonzero false-positive rate. Systems can rotate filters by epoch to bound memory and keep the false-positive rate manageable https://www.usenix.org/legacy/publications/library/proceedings/fast03/tech/full_papers/aguilera/aguilera_html/node7.html. Note that false positives may occasionally reject legitimate messages; choose expiration and rotation to keep this acceptable for your workload.

Where possible, design critical operations to be idempotent. If a client retries due to network loss, idempotent requests avoid harmful repeats even when a duplicate sneaks through https://www.usenix.org/legacy/publications/library/proceedings/fast03/tech/full_papers/aguilera/aguilera_html/node7.html.

TLS is necessary, not sufficient

Use TLS to protect confidentiality and integrity in transit. Modern TLS 1.3 further tightens replay resistance with one-time session tickets, non-replayable handshakes and strict key derivation. Still, application-layer freshness checks remain required to prevent duplicate business actions over HTTPS https://dti-techs.gitbook.io/practical-foundations-in-cybersecurity/5.-cryptography-and-wireless-security/replay-attacks-and-anti-replay-methods.

How to tune windows, TTL and skew

Pick windows for your latency and retry profile

Set sequence-number or timestamp windows to the smallest values that still allow for your typical network jitter and client retries. Monitor drops to ensure you are not rejecting legitimate late or out-of-order messages https://dti-techs.gitbook.io/practical-foundations-in-cybersecurity/5.-cryptography-and-wireless-security/replay-attacks-and-anti-replay-methods. If you use Bloom filter caches, rotate filters by epoch before false positives grow large and ensure epoch data is included in the signed fields https://www.usenix.org/legacy/publications/library/proceedings/fast03/tech/full_papers/aguilera/aguilera_html/node7.html.

For timestamp-based checks, keep TTLs short and allow only modest clock skew. Periodically validate client clock behavior in logs and adjust the skew allowance if you see routine drift.

Common mistakes and how to test

Pitfalls to avoid

• Relying on TLS alone without freshness checks at the application layer https://dti-techs.gitbook.io/practical-foundations-in-cybersecurity/5.-cryptography-and-wireless-security/replay-attacks-and-anti-replay-methods.
• Not storing and checking nonces or timestamps server-side.
• Overlong token lifetimes that widen the replay window.
• Skipping idempotency patterns on endpoints that clients may retry. See Idempotency keys: safe retries without duplicate actions and guidance on retries in Should we retry on 500?.

Practical test

In a controlled environment, record a legitimate request and immediately resend it, then resend it after your timestamp window. The service should accept only the first legitimate instance and reject both replays. Log and alert on rejected replays so you can spot attack spikes or misconfigured clients. If duplicates can occur due to network loss, make the operation idempotent to keep outcomes correct https://www.usenix.org/legacy/publications/library/proceedings/fast03/tech/full_papers/aguilera/aguilera_html/node7.html.

FAQ