What is Nonce?
Definition
A nonce (“number used once”) is a unique, usually random value generated for a single use in a cryptographic operation or protocol message. Nonces stop recorded messages from being accepted a second time (replay protection), keep encryptions under the same key distinct from one another, and, in Content Security Policy, allow only approved inline scripts to run.
Also known as: number used once, cryptographic nonce, CSP nonce, one-time value
Unique, unpredictable, or both?
Every nonce is meant to be used once, but contexts differ in what they demand. Sometimes uniqueness is all that matters: under a given encryption key, the value must simply never repeat, so even a counter works. Elsewhere unpredictability is essential, because a value an attacker can guess in advance protects nothing. Work out which property you need before deciding how to generate it. When in doubt, a cryptographically secure random generator satisfies both.
Stopping replays
Capturing a valid message and sending it again later requires no cryptanalysis at all; the signature is still valid. Nonces close that hole. The server issues or expects a fresh value per exchange, marks it as used the moment it is accepted, and rejects any later message carrying the same value. To avoid remembering every nonce forever, they are usually paired with a timestamp: messages older than a few minutes are rejected outright, so only nonces inside that window need tracking.
The pattern is everywhere. In OpenID Connect the client puts a nonce in the login request and expects the same value back in the ID token, which stops a token minted for another login from being slipped in. Webhook senders commonly sign the payload together with a timestamp using HMAC, and receivers reject stale signatures.
Nonces in encryption: never repeat one
Modern authenticated encryption modes such as AES-GCM and ChaCha20-Poly1305 take a nonce, also called an IV, alongside the key for each message; for AES-GCM it is typically 96 bits. The nonce is not secret and travels in the clear with the ciphertext. Reusing a nonce with the same key, however, is a serious failure: with GCM it leaks information about both plaintexts and undermines the integrity guarantee. Rather than managing nonces by hand, use the high-level interfaces of an established cryptography library that handle this correctly.
CSP nonces: allowing inline scripts one by one
Content Security Policy limits which scripts may run on a page. Instead of 'unsafe-inline', which allows every inline script, a nonce-based policy only runs scripts carrying the value the server generated for this response:
Content-Security-Policy: script-src 'nonce-rT8xZq3VbN1kLmP0aWc5Yg=='
<script nonce="rT8xZq3VbN1kLmP0aWc5Yg==">
window.dataLayer = window.dataLayer || [];
</script>A script injected through an XSS flaw does not know the value and is blocked. Three conditions make this work: generate a fresh value with at least 128 bits of randomness for every response; write it from the server template, never from user input; and do not let a CDN cache the HTML so that everyone receives the same nonce. A cached, fixed nonce is just a password everybody knows. Browsers help too: getAttribute("nonce") returns an empty string, and the value is only reachable through the DOM property. MDN's nonce reference has the details.
WordPress nonces: same name, different job
Many developers first meet the word through the _wpnonce field in WordPress forms. WordPress's own documentation points out that these are not true nonces: they are not single-use and, with default settings, stay valid for between 12 and 24 hours. Their job is to confirm that a request reflects a deliberate user action, reducing CSRF risk. The documentation is explicit that nonces must never be relied on for authorization, and that the user's capability to perform the action must be checked separately.