Skip to content

Why did adding CSP nonces change your HTML caching policy?

1 min read · main part only; folded sections are optional

After this you can answer: Why did adding CSP nonces change your HTML caching policy?

A Content Security Policy tells the browser which content may execute. The proxy overwrites caller-provided nonce and policy headers before forwarding the request, so Next.js can apply the server-generated nonce to its scripts. It also puts the matching policy on the response.

The proxy covers HTML and React Server Component routes while excluding static assets and selected server endpoints. Both it and Next.js headers enforce no-store for the relevant responses. The optional CloudFront events cache configuration therefore does not mean that event HTML is currently stored at the edge.

Public event data can still be cached separately, and hashed static asset URLs can retain their own policy. This distinction matters: disabling shared HTML caching is not the same as removing every useful cache. CSP reduces the impact of some script injection paths, but a trusted script with a bug or hostile runtime data still needs secure application code.

What if the nonce in HTML differs from the header?
The browser blocks scripts that lack a matching authorization. A mismatched cached header or body can break hydration even though the HTML itself arrived successfully.
Does strict-dynamic make trusted scripts harmless?
No. It extends trust to scripts loaded by an authorized script. That can simplify loading, but a compromised trusted script can still cause harm.
Would removing the nonce improve performance?
It could enable a different caching approach, but requires a deliberate CSP design such as hashes and verification of framework output. Security and rendering requirements should be evaluated together.

Read Security headers, then inspect the web-app piece →.

apps/web/src/proxy.ts → proxy

Read this book online: https://book.theversehub.in/