A replay attack occurs when an attacker captures valid data—such as a payment or signed service request—and retransmits it to trigger the same action again. A store might charge one purchase repeatedly, while a modified request could redirect payment to the attacker. The risk is not only interception: without freshness and integrity checks, the system may accept old or altered data as legitimate. section 13.3.3 section 16.2.3
Prevent replay by combining integrity, freshness, and request binding:
- Sign sensitive data so modifications invalidate the signature, and include the HTTP method, path, query parameters, and request-body hash when authorizing service requests. section 13.3.3 section 16.2.3
- Add a timestamp and reject requests outside a narrow validity window, such as five minutes before or after the server clock. section 16.2.3 section 16.4
- Use a nonce, meaning a unique random value used once, and reject authentication responses whose nonce does not match the original request. section 13.3.3 section 13.3
- For magic links and similar credentials, store tokens so the system can detect reuse and invalidate them after their first use. section 14.3
A signed service request
An inventory service signs the string "POST|/adjust-stock|timestamp|SHA256(body)" with its private key. The receiving service verifies the signature with the public key, checks that the timestamp is recent, and rejects a reused or altered request. A valid signature alone is insufficient because an attacker could resend the same signed request hours later. section 16.2.3
