API Replay Attack

Why API replay attacks work

An API replay attack succeeds when a captured request, token, or other bearer credential can be reused without proving it is bound to the original sender, device, or session. The weakness is usually not the API itself, but the trust model around the request.

Replay is especially effective where clients rely on long-lived tokens, static keys, or permissive session handling. If an attacker can observe traffic once, they may be able to repeat an authorised action later, sometimes at scale and without needing to understand the underlying application logic.

Where replay exposure comes from

Replay exposure usually appears when requests are treated as portable proof of authorisation. That is common in mobile apps, distributed services, and API integrations that prioritise convenience over request binding.

Weaknesses often include bearer tokens that remain valid too long, signatures that do not include nonce or timestamp protections, and transport or client layers that do not meaningfully tie a request to a specific device or runtime. In practice, an intercepted request can become a reusable credential.

For API security baselines, organisations often map this problem to request authentication, authorisation, and token handling controls in the OWASP API Security Top 10.

How defenders check and reduce replay risk

Checking exposure starts with understanding which APIs accept bearer-style credentials, where those credentials live, and how long they remain valid. Teams should review whether the API is internet-facing, whether traffic can be intercepted by a malicious app or proxy, and whether vendor or platform guidance recommends sender-constraining or nonce-based validation.

Practical reduction measures usually include short token lifetimes, nonce or timestamp validation, one-time request identifiers, server-side replay caches, and cryptographic proof that a token is bound to the client that presents it. When a stronger sender-constrained design is needed, the relevant standard is RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP), which is designed to make stolen tokens harder to reuse.

For identity and access controls around API callers, teams can also align request handling with NIST SP 800-63 Digital Identity Guidelines and the access, authentication, and audit controls in NIST SP 800-53 Rev 5 Security and Privacy Controls.

Detection and post-replay investigation

Replay attempts are often visible as repeated requests with the same token, same payload, or same transaction pattern from a different IP address, device, geography, or time window. The key detection question is whether a valid request pattern is being reused in a way the original client could not reasonably produce.

After suspected replay, investigate whether the attacker only reused the request or also gained broader access through the same credential. That means checking session logs, token issuance and revocation events, downstream API calls, and any privilege changes made after the replayed request succeeded. If the replay exposed a shared secret or long-lived credential, rotation and invalidation may be needed across every dependent integration.

Where the replay is part of a wider abuse pattern, the attack chain often resembles broader credential theft and reuse behaviour documented in the MITRE ATT&CK Enterprise Matrix.

What good practice looks like in mobile and API integrations

Mobile and API ecosystems need to assume that request data can be observed, copied, and replayed. The right design question is not whether a request can be intercepted, but whether the intercepted material is still useful to an attacker.

Strong designs minimise replay value by using short-lived credentials, binding tokens to the client context where possible, and making each high-value action verifiable as a unique event rather than a reusable message. Where the environment cannot support that model cleanly, compensating controls such as step-up verification, tighter rate limits, narrower scopes, and more aggressive revocation reduce the blast radius.

Teams building a broader API defence programme should also compare replay controls with the surrounding guidance in the OWASP API Security Top 10 and the authentication guidance in NIST SP 800-63 Digital Identity Guidelines, because replay protection is strongest when it is part of the authentication design rather than added later as a patch.

Risk and Threat Considerations

API replay attacks create direct exposure because one captured request can become a reusable authorisation artefact. The risk is highest when the action is valuable, the credential is long-lived, and the server cannot distinguish the original sender from the copier.

Failure mechanism: An attacker captures a valid request or token, then reuses it before expiry or revocation because the API does not sufficiently bind the request to a unique client, session, or one-time context.

Impact: The attacker can repeat authorised actions, move through dependent systems, drain value from transactions, or persist with stolen access until the replayable credential is invalidated.

Practitioner Guidance

What to watch for: Treat replay protection as an authentication design requirement, not a logging or tuning problem. If the same credential can successfully authorise more than one sensitive action without strong sender binding, the design still allows replay.

Practitioner note: The best fix is usually architectural, shorter-lived credentials, stronger proof of possession, and better request uniqueness, rather than trying to detect every replay after the fact.

Related resources from NHI Mgmt Group

• Who is accountable when a JWT token replay attack succeeds across services?
• Why do API-level tests miss real AI agent attack paths?
• How can organisations reduce token replay risk in API and SSO flows?
• How should security teams reduce API attack surface without slowing delivery?