Replay and freshness

What this check verifies

The architecture draft recommends (a SHOULD, not a MUST) that signatures include a nonce parameter, a base64url-encoded random value, with the signer keeping each nonce unique within the signature’s validity window. This check passes when a nonce parameter is present and warns when it is absent.

What the check cannot do is prove uniqueness: a stateless checker sees one request at a time, so whether a nonce is ever reused is enforced operator-side, by the verifier tracking seen nonces. The pass message says exactly that. A valid Web Bot Auth signature can be replayed within its validity window unless something, a nonce store or a short window, stops it.

Why it matters

A signature commits to its covered components and its created/expires window. Within that window the same signed request can be sent again and will verify again, because nothing in the signature itself marks a request as already-seen. Whether that matters depends on what the request does. For an idempotent fetch it is usually harmless; for anything with side effects it can be a real replay risk.

There are two common ways to narrow the gap. A short validity window limits how long a captured signature stays usable. A nonce parameter, recorded and rejected on reuse by the verifier, makes each signature single-use. The draft recommends a 64-byte random nonce; origins may even respond with 429 and request a fresh signature when they suspect a replay.

How to fix it

To clear the warning, include a nonce in @signature-params:

1. Generate a fresh random nonce per request (the draft recommends 64 bytes, base64url encoded); the reference libraries do this for you.
2. Keep the validity window short, only as long as needed between signing and the request arriving. See the validity window advisory.
3. On the verifier side, decide per endpoint how much freshness you require: a read-only endpoint may accept the window alone, while an endpoint with side effects may want nonce tracking or its own idempotency keys.

References

• RFC 9421 defines the nonce, created, and expires parameters relevant to freshness.
• The web-bot-auth architecture draft recommends including a nonce and keeping it unique within the validity window.
• Validity window covers the related window-length advisory.
• How grading works explains why an advisory note never affects the verdict.