Preview draft. Copy and visuals are pending review and may change before launch.

Concept

The role of nonces in preventing replay attacks

The simplest possible attack against a legitimate request is to do nothing to it at all — just send it again.

← Back to the library

Foundations and Principles · Published 2026-09-06

An attack that requires no understanding of the request

A replay attack captures a legitimate request, observed in transit or found somewhere it was logged, and resubmits it later to repeat whatever effect it originally had — without the attacker ever needing to understand, decrypt, or modify the request's actual contents. An exact, unmodified copy is sufficient, as long as nothing about the receiving system detects that this specific request has already been processed once before.

This is what makes replay a distinct threat from most other attack categories: it doesn't exploit a flaw in how a request is validated, only the fact that a valid request, once observed, remains valid indefinitely unless something specifically prevents its reuse.

A value that changes each time closes the gap

A nonce — a value used once and never legitimately repeated — closes this gap by giving the receiving system something concrete to check a request's freshness against: if this exact nonce has already been seen and processed, the request is rejected regardless of how legitimate it otherwise appears. The same protective role can be filled by a strictly increasing sequence number or a tightly bound expiry window, but the underlying principle is identical: some property of the request has to change or expire after its first legitimate use, so a captured copy from an earlier moment fails a check the original submission passed.