A nonce is a number used once: an arbitrary value generated to be unique within a specific context so that it cannot be reused, which lets systems reject replayed requests, authorize specific inline scripts, and guarantee freshness in cryptographic and authentication protocols. The exact requirements vary by use. Sometimes a nonce must be unpredictable, sometimes merely unique, and sometimes both. Getting that distinction right is what separates a working defense from a subtle vulnerability.
Key takeaways
- A nonce is a value meant to be used a single time in a given context, defeating replay and reuse attacks.
- In Content Security Policy, a per-response nonce lets you allow specific inline scripts while blocking injected ones.
- In OAuth and OpenID Connect, nonce and state values bind a response to the original request.
- In cryptography, a nonce guarantees that encrypting the same plaintext twice yields different ciphertext; reuse can be catastrophic.
- Whether a nonce must be secret, unpredictable, or merely unique depends entirely on the use case.
- The cardinal sin is reuse, especially reusing an encryption nonce with the same key.
What does nonce mean and why does uniqueness matter?
Nonce stands for number used once. The core idea is that a fresh value accompanies an operation so the operation cannot be meaningfully repeated. If an attacker captures a valid request and replays it, the system detects the reused nonce and rejects the duplicate.
Uniqueness is the essential property, but different contexts add requirements. A replay defense needs values that are not repeated. A Content Security Policy nonce needs values an attacker cannot predict. An encryption nonce needs values that never repeat under the same key. Confusing these requirements is the source of most nonce bugs.
How does a nonce prevent replay attacks?
A replay attack captures a legitimate message and sends it again to trigger the same effect, such as replaying a payment authorization. A nonce breaks this because the server remembers which nonces it has already accepted and refuses repeats.
A typical flow looks like this:
- The client requests or generates a fresh nonce for the operation.
- The client includes the nonce in the signed or authenticated request.
- The server verifies the nonce has not been seen before and is still within its validity window.
- The server records the nonce as used, so a replay is rejected.
Often a nonce is paired with a timestamp so the server only needs to remember recent nonces rather than an unbounded history. Requests outside the time window are rejected outright, and nonces within it are checked against a short-lived store.
How does a nonce work in Content Security Policy?
Content Security Policy (CSP) reduces cross-site scripting risk by controlling which scripts a page may run. Inline scripts are dangerous because injected ones look just like legitimate ones. A CSP nonce solves this by tagging the scripts you trust with a per-response random value that the policy header also references.
The server generates a fresh nonce for each response and includes it in both the header and the trusted script tags:
Content-Security-Policy: script-src 'nonce-r4nd0mBase64Value'<script nonce="r4nd0mBase64Value">
// this inline script is allowed
</script>
<script>
// an injected script without the nonce is blocked
</script>Because an attacker injecting script cannot know the nonce for that specific response, their script lacks the matching attribute and the browser refuses to execute it. The critical rule is that the nonce must be unpredictable and regenerated on every response; a static or guessable nonce provides no protection.
How are nonces used in OAuth and OpenID Connect?
Authentication and authorization protocols use nonce-like values to tie a response back to the request that started it. In the OAuth authorization code flow with PKCE, the state parameter acts as a nonce that the client generates, sends with the authorization request, and verifies on return to prevent CSRF against the callback.
OpenID Connect, which layers authentication on top of OAuth’s authorization, adds a dedicated nonce parameter. The client sends it in the authentication request, and the identity provider embeds it in the issued ID token. The client then checks that the token’s nonce matches the one it sent, which prevents token replay and injection.
- OAuth is about authorization: granting a client limited access to resources.
- OpenID Connect adds authentication: proving who the user is via the ID token.
- state protects the redirect against forgery; nonce binds the ID token to the request.
Both values must be unpredictable and validated on return, and PKCE additionally protects the code exchange itself.
What role does a nonce play in cryptography?
Many encryption modes and protocols require a nonce, sometimes called an initialization vector, to ensure that encrypting the same plaintext twice does not produce identical ciphertext. This prevents attackers from detecting repeated messages and from mounting certain attacks against the cipher.
The requirement here is strict: for authenticated encryption modes, a nonce must never repeat under the same key. Reusing a nonce with the same key can expose plaintext relationships and, in some modes, catastrophically break confidentiality and integrity. Two safe strategies are:
- Random nonces drawn from a cryptographically secure generator, sized large enough that collisions are negligible.
- Counter-based nonces that increment deterministically and are never reset for a given key.
Note that a cryptographic nonce usually does not need to be secret and is often transmitted in the clear alongside the ciphertext; its job is uniqueness, not confidentiality.
What is the difference between a nonce, a salt, and a CSRF token?
These are all unpredictable or unique values, but they serve different goals and have different lifetimes.
| Value | Primary purpose | Key property | Typical scope |
|---|---|---|---|
| Nonce | Freshness and single use | Unique, often unpredictable | One operation or response |
| Salt | Make each password hash unique | Unique per credential, stored openly | Lifetime of the stored hash |
| CSRF token | Verify request origin | Unpredictable, session-bound | A user session |
A salt is not used once; it persists with the stored hash and simply ensures two identical passwords hash differently. A CSRF token typically lasts a whole session. A nonce is scoped tightly to a single use, which is precisely what its name promises.
What are the most common nonce mistakes?
Nonces fail silently, so mistakes are easy to ship:
- Reuse: the fatal error, especially reusing an encryption nonce with the same key or a CSP nonce across responses.
- Predictability: generating from a counter, timestamp, or weak generator where unpredictability is required, as in CSP.
- No validation: issuing a nonce but never checking it on return, which makes it decorative.
- Unbounded storage: remembering every nonce forever instead of pairing with a timestamp window.
- Too short: using so few bits that collisions or brute force become feasible.
The fix in every case is to match the nonce’s generation and handling to its context: unpredictable and per-response for CSP, never-repeating for encryption, and always verified where replay protection is the goal.
How do I generate a nonce correctly?
The safe default for almost every security use is a cryptographically secure random number generator, not the general-purpose random functions used for shuffling or sampling. Draw enough bytes to make guessing and collisions infeasible, then encode them for transport.
- For unpredictability, as in CSP and OAuth: generate the value from a secure random source and encode it as base64 or hex for placement in headers and attributes.
- For encryption nonces where uniqueness is paramount: follow the specific mode’s guidance, using either a large random nonce or a strictly increasing counter that is never reused with the same key.
- For replay defenses: pair the nonce with a short validity window and a store of recently seen values so you can reject duplicates without remembering them forever.
Whatever the use, regenerate the nonce for each new operation. The most damaging bugs come not from choosing too few bits but from reusing a value that was supposed to be fresh, so build generation into the operation itself rather than caching a nonce and accidentally sending it twice.
Frequently asked questions
What does nonce stand for?
Nonce is short for number used once, a value that is intended to be unique within a given context so it cannot be meaningfully reused by an attacker.
What is a nonce used for?
Nonces prevent replay attacks, authorize inline scripts in Content Security Policy, bind OAuth and OpenID Connect responses to a request, and ensure uniqueness in cryptographic operations.
What is the difference between a nonce and a salt?
A salt makes stored password hashes unique and is stored alongside the hash, while a nonce guarantees freshness or single use for a single operation or session.
Does a nonce need to be secret?
Not always. A CSP nonce is visible in the page source; what matters is that it is unpredictable per response. Cryptographic nonces often need uniqueness more than secrecy.
Can a nonce be reused?
Reusing a nonce defeats its purpose and can be catastrophic, especially in encryption where reusing a nonce with the same key can leak plaintext.
How is a nonce different from a CSRF token?
Both are unpredictable values, but a CSRF token verifies request origin over a session, while a nonce enforces single use or freshness for one specific operation.
How long should a nonce be?
Long enough to be unpredictable for its context, commonly 128 bits or more of randomness for security-sensitive uses like CSP or OAuth state.