CSP hashes and nonces for small static sites that still want strict script rules
Use CSP hashes and nonces intentionally by matching them to static or dynamic site architectures instead of treating them as interchangeable syntax.
Tip
Run the workflow once with a disposable value, then do a decrypt or restore check before you share anything real.
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?”
Summary
Definition: 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.
Pitfall: Using nonces on a static site or hashes on constantly changing dynamic inline output can create needless maintenance pain.
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.
The downside is that every content change requires a new hash. That is not a problem when the build pipeline owns the change.
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.
- Avoid
unsafe-inlinejust because the first strict policy feels inconvenient.
Quick example
Use this when a small static site wants a stricter script-src policy without adding server-side nonce plumbing.
What to notice: Choose the mechanism that matches how the page is actually produced.
Static build with stable inline script -> CSP hash is often the calmer choice
Dynamic templated response -> CSP nonce may fit better
Practical check
- 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.
FAQ
Can a static site use nonces?
Not naturally, because nonces are meant to be fresh per response.
Do CSP hashes replace SRI?
No. They solve related but different enforcement problems.
Developer workflow
Use this guide as a local handling check before a secret or protected file leaves your machine.
- Start with a harmless value that has the same shape as the real secret.
- Run the matching browser tool and copy the result into a scratch note.
- Run the decrypt, restore, or verification step before you share the real output.
1. disposable input
2. browser-only protect/encrypt step
3. decrypt or restore check
4. share only the intended artifact