CSP SRI (hashes) and nonce for ISR pages and custom <Script> tags in <head> of root layout.

[campbellgoe]

Summary

Hi,

I'm looking into implementing the CSP (Content-Security-Policy) for my webapp.

I followed this amazing guide at https://nextjs.org/docs/app/guides/content-security-policy

I'd like to use the experimental SRI for specifying the hash for scripts, however I have a <Script> in my root layout.tsx which requires a nonce.

Is it possible to combine the SRI hash CSP with a nonce based CSP?

I'd much prefer to keep static or ISR pages over pages rendered on the server dynamically every time, for performance reasons.

This is simply an analytics Script so it's not entirely necessary but it would be great if it's possible to keep the advantages of SRI and ISR over all dynamic pages simply for an analytics script.

Any suggestions on how I'd go about implementing this?

Here's my first attempt:

SRI in next.config.mjs

import path from "node:path"
import { fileURLToPath } from "node:url";
const isDev = process.env.NODE_ENV === 'development'
// automatic hash based CSP instead of nonces , allowing ISR instead of dynamic slow loading pages with nonces
// see https://nextjs.org/docs/app/guides/content-security-policy
const cspHeader = `
    default-src 'self';
    script-src 'self'${isDev ? " 'unsafe-eval'" : " 'strict-dynamic' https://ghostlyx.com"};
    style-src 'self';
    img-src 'self' blob: data:;
    font-src 'self';
    object-src 'none';
    base-uri 'self';
    form-action 'self';
    frame-ancestors 'none';
    upgrade-insecure-requests;
`

const __dirname = path.dirname(fileURLToPath(import.meta.url));
/** @type {import('next').NextConfig} */
const nextConfig = {
  typescript: {
    ignoreBuildErrors: false,
  },
  images: {
    unoptimized: false,
  },
  turbopack: {
    root: path.join(__dirname),
  },
  experimental: {
    sri: {
      algorithm: 'sha256',
    },
  },
  async headers() {
    return [
      {
        source: '/(.*)',
        headers: [
          {
            key: 'Content-Security-Policy',
            value: cspHeader.replace(/\n/g, ''),
          },
        ],
      },
    ]
  },
}

export default nextConfig

And extract from my proxy.ts file:

let response
  const enableNonceCsp = process.env.ENABLE_NONCE_CSP === 'true'
  if(enableNonceCsp){
  const nonce = Buffer.from(crypto.randomUUID()).toString('base64')
  const isDev = process.env.NODE_ENV === 'development'
  const cspHeader = `
    default-src 'self';
    style-src 'self'${isDev ? " 'unsafe-eval'" : ''} 'nonce-${nonce}' 'strict-dynamic' https://ghostlyx.com;
    img-src 'self' blob: data:;
    font-src 'self';
    object-src 'none';
    base-uri 'self';
    form-action 'self';
    frame-ancestors 'none';
    upgrade-insecure-requests;
`
  // Replace newline characters and spaces
  const contentSecurityPolicyHeaderValue = cspHeader
    .replace(/\s{2,}/g, ' ')
    .trim()

  const requestHeaders = new Headers(request.headers)
  requestHeaders.set('x-nonce', nonce)

  requestHeaders.set(
    'Content-Security-Policy',
    contentSecurityPolicyHeaderValue
  )

  response = NextResponse.next({
    request: {
      headers: requestHeaders,
    },
  })
  response.headers.set(
    'Content-Security-Policy',
    contentSecurityPolicyHeaderValue
  )
}  else{
  response = NextResponse.next()
}

I'm not sure how to resolve the conflict between these two and enable both SRI hash CSP and nonce-based CSP specifically for this script in root layout.tsx:

import { cn } from "@/lib/utils";
import type { Metadata, Viewport } from "next"
import { Geist, Geist_Mono, Source_Serif_4 } from 'next/font/google'
import { headers } from "next/headers";
import Script from "next/script";
import RootLayoutClient from "./rootLayout.client";
const _geist = Geist({ subsets: ['latin'], weight: ["100", "200", "300", "400", "500", "600", "700", "800", "900"] })
const _geistMono = Geist_Mono({ subsets: ['latin'], weight: ["100", "200", "300", "400", "500", "600", "700", "800", "900"] })
const _sourceSerif_4 = Source_Serif_4({ subsets: ['latin'], weight: ["200", "300", "400", "500", "600", "700", "800", "900"] })

export const metadata: Metadata = {
  title: "Create Professional Invoice Documents",
  description:
    "Create targeted, professional invoices and receipts.",
}

export const viewport: Viewport = {
  themeColor: [
    { media: "(prefers-color-scheme: light)", color: "#ffffff" },
    { media: "(prefers-color-scheme: dark)", color: "#0a0a0a" },
  ],
}

export default async function RootLayout({
  children,
}: {
  children: React.ReactNode
}) {
   const nonce = (await headers()).get('x-nonce')
    return (
      <html lang="en-GB">
        <head>
          <Script
          defer
          data-domain="redacted"
          data-site-id="redacted"
          src="https://ghostlyx.com/js/script.js"
          nonce={nonce || undefined}/>
        </head>
        <body className={cn(`font-sans antialiased`, {
          'overflow-x-hidden': true
        })}>
          <RootLayoutClient>{children}</RootLayoutClient>
      </body>
    </html>
    )
  }

Any help is appreciated!

Additional information

No response

Example

No response

[ryanportfolio]

I don't think you can keep a per-request nonce and keep ISR/static at the same time. A nonce has to be unique per request, and Next only injects it during server-side rendering, so using one forces every page to render dynamically.

The experimental sri feature is the static-friendly alternative to nonces, so for the ISR/static path the move is to use SRI and drop the nonce entirely. SRI hashes your own build-time JS and adds integrity attributes to those script tags, which is what lets you keep a strict CSP without a nonce.

Your analytics <Script src="https://ghostlyx.com/js/script.js"> is a separate problem. SRI only hashes the JS files Next builds, not a third-party external script, so it won't cover that tag. On a no-nonce static page you allowlist the host in script-src instead, and drop the nonce={nonce} prop from that Script (a static page has no nonce to read anyway).

One potential bug in your setup: your production CSP is script-src 'self' 'strict-dynamic' https://ghostlyx.com. 'strict-dynamic' tells the browser to ignore 'self' and every host in the list, including https://ghostlyx.com, and only trust scripts allowed by a nonce or hash. On the static path you have neither, so nothing bootstraps trust and this policy blocks your scripts (Next's own bundles and the analytics). That's why Next's SRI example uses a plain script-src 'self'.

So for the static/ISR path, drop 'strict-dynamic' and allowlist the host:

// next.config.mjs
const cspHeader = `
  default-src 'self';
  script-src 'self' https://ghostlyx.com;
  style-src 'self';
  img-src 'self' blob: data:;
  font-src 'self';
  object-src 'none';
  base-uri 'self';
  form-action 'self';
  frame-ancestors 'none';
  upgrade-insecure-requests;
`
// keep your existing experimental.sri config

This keeps ISR: Next's own scripts pass via 'self' plus the integrity check, the analytics passes via the host allowlist. Combining SRI with a nonce is possible per the docs, but only on dynamically rendered pages, which defeats your goal.

btw in your proxy.ts nonce branch, 'nonce-...', 'strict-dynamic', and the dev 'unsafe-eval' are on style-src and there's no script-src line, so scripts fall back to default-src 'self'. If you ever use that branch I'd move those to script-src.)

[devashmit]

You're mixing two CSP strategies that have different trade-offs, and unfortunately they don't complement each other in the way we'd like.

The experimental experimental.sri feature is designed for static/ISR pages. It works by generating integrity hashes for the scripts that Next.js emits at build time, allowing you to avoid per-request nonces and keep pages static.

A nonce-based CSP, on the other hand, is inherently request-specific. Every request gets a new random nonce, which means the page has to be rendered dynamically so the nonce can be injected into both the CSP header and the corresponding <script> tags. This is why the Next.js CSP guide recommends nonces for dynamic rendering and SRI for static rendering rather than combining them.

For your analytics script specifically, you have a few options:

1. Keep the app on SRI and whitelist the analytics origin

Since your script is external:

<script src="https://ghostlyx.com/js/script.js"></script>

you can simply allow that origin in script-src:

script-src 'self' https://ghostlyx.com;

This lets you keep ISR/static rendering without introducing nonces.

2. Use a hash only if the script is inline

Hashes are intended for inline scripts with known content. They don't help for an external script whose contents may change over time unless you manage the hash yourself.

3. Use a nonce only if you actually need one

If the analytics provider requires an inline bootstrap script or you need to authorize dynamically generated scripts, then a nonce is the correct solution. In that case, you'll have to accept dynamic rendering for those pages.

One thing I noticed in your example is that you're generating a nonce only when ENABLE_NONCE_CSP is enabled, but you're always reading x-nonce in layout.tsx. With SRI enabled that header will be null, so I'd avoid trying to support both modes simultaneously. Instead, make them mutually exclusive based on configuration:

• SRI mode → static/ISR + no nonce + allow trusted external origins.
• Nonce mode → dynamic rendering + per-request nonce.

Out of curiosity, does ghostlyx.com require the nonce attribute, or is it just an external analytics script? If it's the latter, I'd probably stay with the SRI/static approach and simply allow the origin in script-src, since that preserves the performance benefits you're aiming for.

[MILLERMARRU]

You can keep ISR, keep SRI, and still load the analytics script, and the trick is that you do not need the nonce at all. The key is how strict-dynamic treats scripts that are added to the DOM at runtime.

Under CSP3, strict-dynamic propagates trust: any script that was itself authorized (by hash or nonce) may create new script elements via DOM APIs, and those inherit authorization. next/script with the default afterInteractive strategy (and lazyOnload) injects the tag with DOM insertion, it is not parser-inserted. So the chain becomes: build-time SRI hashes authorize the Next.js runtime chunks, the runtime executes your <Script src="https://ghostlyx.com/..."> by appending it to the DOM, and strict-dynamic extends trust to it. No nonce, no per-request rendering, page stays ISR.

So concretely: keep experimental.sri and the hash sources in script-src along with 'strict-dynamic', drop the nonce prop from the Script tag, and make sure the strategy is not beforeInteractive (that one goes into the initial HTML as a parser-inserted tag, which would need its own hash or nonce and breaks the static story).

One thing in your draft to be aware of: with strict-dynamic present, CSP3 browsers ignore host allowlists like https://ghostlyx.com in that directive, so it neither helps nor hurts, it just acts as a fallback for old browsers that only understand CSP2. Fine to leave in for that reason.

The combination you asked about literally (nonce plus hashes in the same policy) is technically allowed by the spec, both are valid sources, but it buys you nothing here because generating the nonce is what forces dynamic rendering. Once you realize the analytics script can ride on strict-dynamic trust propagation instead, the nonce has no job left to do. Verify in devtools that the tag really lands via DOM injection (it will not have the nonce attribute and appears after hydration) and check the console for CSP reports with report-only mode first, which is a sane rollout for any of this.

[zaccesss]

The short answer is that there isn't a way to combine per-request nonces with static/ISR rendering in the way you're hoping.

A CSP nonce is generated for every request and must appear both in the CSP header and the corresponding <script> tags. Since static and ISR pages are produced ahead of time, Next.js cannot inject a fresh nonce into them, which is why enabling nonce-based CSP forces dynamic rendering.

If your goal is to preserve ISR/static rendering, the recommended approach is:

• Keep experimental.sri enabled.
• Remove the nonce from your <Script> component.
• Allow your analytics origin in script-src if it's an external script.

One thing I also noticed is that your production policy currently contains:

script-src 'self' 'strict-dynamic' https://ghostlyx.com

If the analytics script is parser-inserted (for example beforeInteractive), strict-dynamic won't do what you expect because host allowlists are ignored by CSP3 browsers once strict-dynamic is present unless trust is bootstrapped by a nonce or hash.

If the script is loaded after hydration via next/script (afterInteractive or lazyOnload), then the runtime can bootstrap trust from the SRI-protected Next.js bundles, which lets you keep ISR without introducing nonces.

So the practical options are:

• Static/ISR → SRI + no nonce.
• Dynamic rendering → nonce-based CSP.
• Static/ISR + external analytics → SRI and load the analytics script after hydration (or simply allowlist the origin if you don't need strict-dynamic).

Unfortunately this isn't a Next.js bug so much as a limitation of how CSP nonces work. The Next.js documentation separates SRI and nonce-based CSP because they're intended for different rendering strategies.

[jmrplens]

Taking the literal question first: yes, the guide says they combine: "For dynamic rendering scenarios, you can still generate nonces with proxy if needed, combining both SRI integrity attributes and nonce-based CSP approaches", but only on dynamically rendered pages, which is the thing you're trying to avoid. On the static/ISR path experimental.sri cannot stand in for the nonce, and the configuration this thread has converged on won't work either. Two separate reasons.

1. SRI puts no hash into your policy. It only attaches integrity to the external scripts Next emits (app-render/required-scripts.tsx: bootstrapScript.integrity = SRIManifest[files[0]]), which is what the guide means by "SRI works independently by adding integrity attributes to your assets". A hash-source authorises an external script only if it is in your script-src and the tag's integrity digest is among those hash-sources (CSP3 §6.7.2.4: if the policy has no hash-sources it returns "Does Not Match" immediately). So nothing bootstraps trust. @ryanportfolio is right that under 'strict-dynamic' your 'self' and https://ghostlyx.com are both ignored. That also means the later suggestion in this thread, keeping 'strict-dynamic' and letting the SRI-protected bundles propagate trust to the analytics tag, can't get started: the bundles themselves are unauthorised, so there is no runtime to do the propagating.

2. Dropping 'strict-dynamic' still breaks, and that part hasn't come up yet. The RSC payload ships as inline scripts, built with a nonce or with nothing:

// app-render/use-flight-response.tsx
const startScriptTag = nonce
  ? `<script nonce="${htmlEscapeAttributeString(nonce)}">`
  : '<script>'

integrity never lands on those, and wouldn't help if it did: CSP admits an inline script only via 'unsafe-inline', a matching nonce, or a hash of its content in the policy (CSP3 §6.7.3.3). SRI validates a fetched subresource; an inline script fetches nothing. So on a static or ISR page with script-src 'self' and no nonce, Next's own inline scripts are blocked and the page never hydrates: open issue #95354, reproduced on canary with Minified React error #412. A tell-tale in the guide itself: the "Without Nonces" example uses script-src 'self' 'unsafe-inline', while the SRI example quietly drops the 'unsafe-inline'. Both can't be right.

Pinning hashes by hand doesn't rescue it either, because the inline payload changes per page and per build, and Next's own SRI test notes that some flight-loaded chunks in the initial HTML get no integrity at all.

So today it's 'unsafe-inline' in script-src on the static path, or a nonce with dynamic rendering. Since this is only analytics, the pragmatic version of ryanportfolio's advice: drop 'strict-dynamic', allowlist https://ghostlyx.com, drop the nonce prop, but keep 'unsafe-inline' in script-src until #95354 lands, or you'll be debugging a dead page rather than a blocked tag. (He also spotted that in your proxy.ts branch the nonce, 'strict-dynamic' and the dev 'unsafe-eval' sit on style-src with no script-src line at all.)

If you self-host behind a proxy you control there's a third path, though it isn't a Next recipe and I've only run it on nginx in front of a static site: render a constant sentinel where the nonce goes, cache that, and mint a fresh value per response at the edge, rewriting body and CSP header together and marking the result no-store. Cache the sentinel, never the substituted output. Either way, #95354 is the one to watch.