Next.js 16.2.2 requires dynamic rendering for nonce-based CSP and supports experimental SRI. Harden XSS paths with this reference. Read now.
Nonce-based CSP Needs Dynamic Rendering
Next.js 16.2.2 ties nonce-based Content Security Policy to dynamic rendering. A nonce must be unique per response. If a page is fully static or heavily cached as a fixed HTML shell, the same nonce can leak across users or requests, which defeats the purpose of the policy. Plan routes that inject scripts or styles under a nonce to render on demand so each response can carry a fresh value.
Wire CSP generation at the edge of the request lifecycle: create the nonce early, pass it into the headers that set the policy, and thread the same value into every inline script or style tag you still need. Prefer external bundles with strict script-src and style-src directives over inline markup. When you must keep inline code, require the matching nonce attribute and avoid unsafe fallbacks such as unsafe-inline unless you have a temporary migration path and a clear end date for removing it.
Use Experimental SRI as a Second Layer
Subresource Integrity checks that a script or stylesheet the browser loads matches a known hash. Next.js 16.2.2 supports experimental SRI, which helps when third-party or CDN assets could be swapped or corrupted in transit. Treat SRI as a complement to CSP, not a replacement: CSP constrains where code may run; SRI verifies that the bytes you load are the bytes you approved.
Enable experimental SRI only after you understand how your deploy pipeline produces asset hashes. Rebuilds change hashes, so integrity attributes must be regenerated with each release. Prefer first-party assets you control end to end. For third-party scripts, pin exact versions, store their integrity hashes in config, and fail closed if a hash cannot be verified rather than silently dropping the check.
Close Common XSS Paths in App Code
CSP and SRI reduce blast radius; they do not fix unsafe rendering. Audit every place user or third-party data reaches the DOM. React’s default escaping helps for text nodes, but dangerous patterns still appear in real apps: raw HTML injection, unsafe URL schemes in links and redirects, and dynamic attribute values built from untrusted input.
- Avoid raw HTML APIs unless the content is strictly sanitized with a maintained library and a tight allowlist of tags and attributes.
- Validate and encode URLs before putting them in
href,src, or redirect targets; blockjavascript:and unexpected protocols. - Keep secrets and auth tokens out of client-readable markup and global script variables.
- Serialize data into the page only through safe channels; do not concatenate JSON into inline scripts without proper escaping.
- Review third-party widgets and tag managers; load them only on routes that need them and under the same CSP rules as first-party code.
Practical Hardening Order
Work in layers. First, make dynamic rendering available on any route that issues nonces. Second, ship a strict CSP with nonces (or hashes) for remaining inline assets and drop broad unsafe directives as soon as the app still builds and runs. Third, turn on experimental SRI for static assets you control and document how hashes refresh in CI. Fourth, run a focused XSS review of forms, rich text, search, previews, and any admin tooling that accepts HTML or Markdown.
Finally, test the failure modes: a missing nonce should block the script, a wrong SRI hash should refuse the asset, and a malicious string in a form field should never become executable markup. Log CSP violation reports in a staging environment before tightening production so you can fix legitimate blockers without guessing. This cheat sheet is a reference for that sequence—not a one-time toggle—because XSS hardening holds only when policy, asset integrity, and application code stay aligned after every deploy.