Protect & Encrypt
CSP hashes and nonces for small static sites that still want strict script rules
Choose CSP hashes for fixed scripts and nonces for responses generated per request. Learn how each approach changes your script policy and deployment.
Small sites often want a stricter CSP but assume that means a giant framework project or a policy they cannot realistically maintain. In practice, hashes and nonces each fit different site shapes.
The design question is not “which one is stronger?” It is “which one fits the way this site actually delivers scripts?”
In brief
What it is: CSP hashes allow specific inline blocks by matching their content digest, while CSP nonces allow blocks tagged with a fresh unpredictable value per response.
Why it matters: The right choice lets a site tighten script rules without falling back to broad unsafe allowances.
Worth knowing: Hashes usually fit stable static assets, while nonces usually fit dynamic responses that can issue a fresh value.
Hashes fit stable inline content
If the inline script or style content is stable between builds, hashes are often a strong fit. You compute the digest once per content change and embed it in the policy. That makes hashes especially friendly for static sites and build-based publishing flows.
Every content change requires a new hash, which fits naturally when the build pipeline owns the update.
Nonces fit dynamic responses
A nonce works better when inline blocks are generated dynamically per response. The server creates a fresh unpredictable value and applies it consistently in both the CSP header and the relevant tags. That is powerful, but it assumes a dynamic response path that a purely static site may not have.
The point is architectural fit. A nonce strategy on a static site is usually awkward because the per-response generation model is missing.
- Stable build output -> hashes are often simpler.
- Dynamic per-response inline output -> nonces are often better.
- Prefer a hash or nonce workflow that fits the page's rendering model when the first strict policy needs refinement.
See it in a small example
Worth knowing: The page's rendering model usually determines which mechanism fits more naturally.
Static build with stable inline script -> CSP hash is often the calmer choice
Dynamic templated response -> CSP nonce may fit better
What to verify
- Choose hashes for stable build output and nonces for dynamic response paths.
- Treat the CSP mechanism as part of the site architecture, not just a header string.
- Prefer a strict maintainable policy over a symbolic strict policy that developers immediately work around.
After deployment, paste the complete response-header block into the Security Headers Inspector to keep enforced and report-only CSP separate and review the policy in its wider browser-header context.
Common questions
Can a static site use nonces?
Nonces fit dynamic responses that can issue a fresh value each time. Static sites usually fit stable hashes more naturally.
Do CSP hashes replace SRI?
They solve related but different enforcement problems.
