5 Ways to Prevent API Replay Attacks: From Nonces to Idempotency Keys

An API replay attack occurs when an attacker captures a legitimate request — including parameters, headers, body, and signatures — and resends it unchanged to the server, tricking the server into executing the same business logic multiple times. A classic example is a transfer request intercepted and replayed, causing multiple deductions.

Core characteristic

The request itself is valid; the problem is its duplicate transmission. Replay may happen immediately or after minutes or hours, so defenses must handle both scenarios.

Solution 1: Unique random number (nonce) stored in Redis

Each client request carries a globally unique random number A. The server stores this nonce in Redis with an expiration time (e.g., 10 minutes). On subsequent requests with the same nonce, the server detects the duplicate and rejects the business logic.

Trade‑off: simple to implement, but high request volumes can consume significant Redis memory.

Solution 2: Timestamp validation

The client sends its current timestamp with each request. The server compares the request timestamp with its own clock; if the difference exceeds a configured window (e.g., 5 minutes), the request is rejected.

Limitation: within the allowed time window, an attacker can still replay the same request repeatedly. Therefore, timestamps are usually combined with nonces.

Solution 3: Signature + timestamp + nonce

The client builds a signature by encrypting the request parameters, a nonce, and a shared secret key known only to client and server. The request also carries a timestamp. The server first checks whether the timestamp falls within the validity window; if not, it rejects immediately. If the timestamp is valid, the server recomputes the signature using the same rule (parameters + nonce + secret) and compares it with the received signature. A mismatch leads to rejection; a match allows business processing.

This approach ensures that even if an attacker intercepts the request, they cannot forge a valid signature without the secret key. The nonce guarantees that within the validity window the same request cannot be replayed.

Solution 4: Backend‑issued one‑time token

Before calling the business API, the client first requests a unique token from the backend. The backend generates the token, caches it in Redis with an expiration, and returns it. The client then includes this token in the actual business request. The server checks Redis:

If the token is absent, the request is rejected.

If the token exists, the server processes the business logic and then deletes the token from Redis, ensuring any subsequent request with the same token will be rejected.

Solution 5: Unique idempotency key for core interfaces

For critical operations such as order placement, payment, or refund, the client must supply a unique idempotency key (e.g., order ID, payment serial number). The server guarantees that a request with the same idempotency key is executed only once at the business layer. Even if the request is replayed, the duplicate execution is harmless because the business logic enforces single execution per key.

This method shifts replay protection to the business level, making it independent of transport‑layer mechanisms.