A CSP nonce is a unique, random value generated per page load that helps validate legitimate inline scripts within a Content Security Policy. By adding this nonce to both the CSP header and allowed script tags, developers can permit specific inline scripts while maintaining strong XSS protections. This approach is particularly useful when dynamic script insertion is necessary but a strict CSP is desired.
A CSP nonce (number used once) is a random, unguessable token the server generates on every response and places in two spots: the nonce-... source in the Content-Security-Policy header and a matching nonce attribute on each inline <script> or <style> it wants to allow. The browser executes an inline script only when its nonce attribute matches the value declared in the header for that exact page load. Because the token is regenerated per request and never predictable, markup an attacker injects later cannot carry a valid nonce, so the browser refuses to run it. This lets a site keep the inline scripts it genuinely needs while dropping the blanket unsafe-inline allowance that XSS relies on.
Most XSS defences collapse the moment a policy has to allow unsafe-inline, because that keyword tells the browser to trust every inline script, including any an attacker manages to inject. A nonce-based policy removes that keyword: only inline code the server deliberately stamped with the current token can run. This shrinks the attack surface for reflected, stored, and DOM-based XSS without maintaining long allowlists of external hosts, and it neutralises injected event handlers and inline script tags planted through a vulnerable template. The nonce is the practical route to a strict CSP, the configuration security teams recommend, on real pages that still depend on some inline JavaScript.
Generate the nonce from a cryptographically secure random source (at least 128 bits) and issue a fresh one per response; reusing a nonce across cached pages defeats the purpose. Never place it where an attacker can read and echo it back. Pair it with strict-dynamic so trusted scripts can load their own dependencies, and keep a host allowlist as a fallback for older browsers. Because a nonce still trusts whatever an allowed script does at runtime, it cannot stop a compromised third-party file. cside complements CSP here by routing third-party scripts through a Script method and analysing the actual payload, blocking malicious behaviour in real time that a valid nonce would have waved straight through.
Yes. A nonce must be freshly generated for each HTTP response using a secure random generator. If you cache a page together with its nonce, or reuse the same value, an attacker who observes one valid nonce could replay it inside injected markup, which defeats the protection. Static or cached pages usually need hashes instead.
Both let specific inline scripts run under a strict policy. A nonce is a random per-request token added to the tag and the header, ideal for server-rendered pages. A hash is a fixed digest of the script's exact contents, better suited to static or cached content where you cannot stamp a fresh token on every response.
We answer client-side security questions every day. Bring yours.