Replay and freshness

What this check verifies

This check reads whether the signature carries a nonce parameter and says what that means for replay. It passes either way:

• With a nonce: pass. Whether a nonce is ever reused can only be checked by a verifier that records the nonces it has seen; a stateless checker sees one request at a time.
• Without a nonce: pass. The protocol draft defines no nonce requirement of its own. It points to RFC 9421, section 7.2.2, for replay protection, including the use of a nonce (draft-ietf-webbotauth-httpsig-protocol-00, section 5.2.3).

Earlier versions of the draft recommended a nonce, and this check used to warn when it was missing. It no longer does.

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. A signature that covers only @authority verifies against any method, path, or body sent to that authority until it expires (section 5.2).

Three things narrow that gap:

1. A short validity window limits how long a captured signature stays usable.
2. Covering more components, such as @method and @path, limits what a captured signature can be reused for.
3. A nonce, recorded by the verifier and rejected on reuse, makes each signature single-use. Whether a verifier requires and enforces nonces is its own policy (Appendix C.6).

An origin that sees a signature or nonce used more often than its policy allows may ask for a new signature and answer with 429 (section 5.3).

How to fix it

Nothing is required for this check. To reduce replay risk:

1. Keep the validity window short, only as long as needed between signing and the request arriving. See the validity window advisory.
2. Sign each request when you send it. A precomputed signature reused across many requests can be replayed like a bearer token (section 6.9).
3. Add a fresh random nonce per request if the verifiers you send to track nonces.

On the verifier side, decide per endpoint how much freshness you need: 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; section 7.2.2 covers replay.
• The Web Bot Auth protocol draft (draft-ietf-webbotauth-httpsig-protocol-00): section 5.2.3 adds no nonce requirement, section 6.9 covers static signatures, and Appendix C.6 covers freshness and replay.
• Validity window covers the related window-length advisory.
• How grading works explains how informational checks affect the score.