Skip to main content
A Content Security Policy (CSP) protects your Next.js application against cross-site scripting (XSS), clickjacking, and other code injection attacks by specifying which content sources the browser is allowed to load.

Static CSP headers

For applications that don’t require nonces, set CSP headers directly in next.config.js:
In development, 'unsafe-eval' is required because React uses eval for enhanced debugging. It’s not needed or used in production.

Nonce-based CSP

A nonce is a unique, random string generated per request that allows specific inline scripts to run even under a strict CSP. This is more secure than 'unsafe-inline' but requires dynamic rendering for every page.

Adding nonces with middleware

Generate a fresh nonce for each request in middleware and pass it as both a header and a CSP directive:
Scope the matcher to avoid adding CSP headers to static assets and prefetch requests:

How nonces work in Next.js

Pages must be dynamically rendered to use nonces (static pages have no request headers at build time). Here’s the flow:
  1. Middleware generates a nonce and adds it to the Content-Security-Policy and x-nonce headers
  2. During rendering, Next.js parses the CSP header and extracts the nonce from the 'nonce-{value}' pattern
  3. Next.js automatically attaches the nonce to framework scripts, page bundles, inline styles, and <Script> components

Forcing dynamic rendering for nonces

If a page doesn’t use dynamic APIs, opt it into dynamic rendering:

Reading the nonce in a Server Component

Performance implications of nonces

Using nonces requires dynamic rendering for every page, which means:
  • Pages are generated on each request (no static caching)
  • CDNs cannot cache dynamic pages by default
  • Partial Prerendering (PPR) is incompatible with nonce-based CSP
Use nonces when your security requirements prohibit 'unsafe-inline' or when handling sensitive data.

Subresource Integrity (experimental)

As an alternative to nonces, Next.js supports hash-based CSP using Subresource Integrity (SRI). SRI generates cryptographic hashes of JavaScript files at build time, allowing static generation while maintaining strict CSP.
Benefits over nonces:
  • Pages can be statically generated and cached
  • CDN-compatible
  • Hashes are computed at build time
Limitations:
  • Experimental; behavior may change
  • App Router only
  • Cannot handle dynamically generated scripts

Third-party scripts

When using third-party scripts, add their domains to the CSP and pass the nonce:
Update the CSP to allow the third-party domain:

Troubleshooting

Version history