Next.js

Nonce-Based CSP in Next.js 16: Middleware to proxy.ts

Implementing nonce-based Content Security Policy in Next.js 16 using proxy.ts instead of middleware.ts. Full code, CSP directives, common mistakes.

Nonce-Based CSP in Next.js 16: Migrating From Middleware to proxy.ts | AI PM Portfolio

Nonce-Based CSP in Next.js 16: Migrating From Middleware to proxy.ts

April 11, 2026 · 11 min read · Next.js + Supabase + AI

Last Updated: 2026-04-11

Next.js 16 replaces middleware.ts with proxy.ts for request interception. If your Content Security Policy relied on middleware to generate per-request nonces, the build now fails when both files coexist. The migration path: generate a cryptographic nonce in proxy.ts (which runs in full Node.js, not the Edge runtime), set the CSP header with that nonce, pass it to layout.tsx via a custom x-nonce header, and inject it into every Script component. The result is stronger CSP with fewer runtime constraints.

Why does CSP with nonces matter for production apps?

Content Security Policy is a browser-enforced HTTP header that controls which scripts, styles, and resources can execute on your page. Without CSP, any script injected via XSS runs with full access to the DOM, cookies, and user session. According to the OWASP Top 10, Cross-Site Scripting remains the most common web application vulnerability, appearing in approximately 65% of all applications tested in 2024.

A nonce-based CSP assigns a unique, cryptographically random token to every HTTP response. Only scripts carrying that exact nonce can execute. This eliminates the need for 'unsafe-inline' in your script-src directive — the single most common CSP weakness. According to a Google Web Fundamentals analysis, 95% of deployed CSP policies are bypassable because they rely on allowlists instead of nonces or hashes.

I implemented nonce-based CSP in a production tax application handling PII (Social Security numbers, dates of birth, financial data). The security audit required eliminating 'unsafe-inline' for scripts while keeping Stripe.js, Sentry, and a scheduling widget operational. That combination — strict CSP plus third-party scripts — is where most implementations break. I covered security hardening patterns for PII applications in a previous post.

How did CSP work in Next.js 15 with middleware.ts?

In Next.js 15, the standard pattern for nonce-based CSP used middleware.ts. The middleware ran on every request, generated a nonce, set the CSP header, and passed the nonce downstream via a custom request header. Here is what that looked like:

// middleware.ts (Next.js 15 pattern — no longer works in Next.js 16)
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export function middleware(request: NextRequest) {
  // Generate a random nonce for this request
  const nonce = Buffer.from(crypto.randomUUID()).toString('base64');

  // Build the CSP header
  const cspHeader = `
    default-src 'self';
    script-src 'nonce-${nonce}' 'strict-dynamic';
    style-src 'self' 'unsafe-inline';
    img-src 'self' data: https:;
    font-src 'self';
    connect-src 'self' https://*.supabase.co https://*.stripe.com https://*.sentry.io;
    frame-src 'self' https://*.stripe.com;
    object-src 'none';
    base-uri 'self';
  `.replace(/\n/g, ' ').trim();

  const response = NextResponse.next();
  response.headers.set('Content-Security-Policy', cspHeader);
  // Pass nonce to layout via custom header
  response.headers.set('x-nonce', nonce);
  return response;
}

Then in layout.tsx, you read the nonce from headers and injected it into Script components:

// app/layout.tsx (Next.js 15 pattern)
import { headers } from 'next/headers';
import Script from 'next/script';

export default async function RootLayout({ children }) {
  const headersList = await headers();
  const nonce = headersList.get('x-nonce') ?? '';

  return (
    <html lang="en">
      <head>
        <Script src="https://js.stripe.com/v3/" nonce={nonce} strategy="beforeInteractive" />
      </head>
      <body>{children}</body>
    </html>
  );
}

This approach had three limitations. First, middleware runs on the Edge runtime, which restricts access to Node.js APIs like fs, net, and most native modules. Second, the nonce had to be threaded through request headers, response headers, and layout props — three layers of plumbing. Third, middleware intercepts all requests (including static assets) unless you carefully configure matchers, adding unnecessary latency to image and font requests.

What changed in Next.js 16 that breaks this pattern?

Next.js 16 introduced proxy.ts as the replacement for middleware.ts for request interception. If you have both files in your project root, the build fails with a clear error:

Error: Both middleware file "./middleware.ts" and proxy file "./proxy.ts" are detected.
Please use "./proxy.ts" only.

The key architectural difference: proxy.ts runs in a full Node.js environment, not the Edge runtime. This means access to all Node.js APIs, no 1MB code size limit, and no restrictions on native modules. For CSP nonce generation specifically, this means you can use crypto.randomBytes() instead of the Web Crypto API — not that it matters much for nonces, but it signals the broader runtime shift.

The migration is not just renaming a file. The proxy.ts API surface is different from middleware. It uses an InterceptedRoute pattern with explicit route matching, and it integrates with Supabase auth sessions via updateSession() out of the box in most Supabase + Next.js setups. I wrote about Next.js App Router patterns and SSR pitfalls in an earlier post.

How do you implement nonce CSP with proxy.ts?

Step 1: Generate the nonce in proxy.ts

The proxy file intercepts incoming requests before they reach your route handlers and layouts. Here is the full proxy.ts with CSP nonce generation:

// proxy.ts (project root)
import { createServerClient } from '@supabase/ssr';
import { NextRequest, NextResponse } from 'next/server';

export function proxy(request: NextRequest) {
  // Generate a cryptographic nonce for this request
  const nonce = Buffer.from(crypto.randomUUID()).toString('base64');

  // Construct the CSP header with the nonce
  const cspHeader = buildCspHeader(nonce);

  // Create the response (or delegate to Supabase session handling)
  const response = NextResponse.next({
    request: {
      headers: new Headers({
        ...Object.fromEntries(request.headers),
        'x-nonce': nonce, // Pass nonce to layout.tsx
      }),
    },
  });

  // Set the CSP header on the response
  response.headers.set('Content-Security-Policy', cspHeader);

  // Additional security headers
  response.headers.set('X-Content-Type-Options', 'nosniff');
  response.headers.set('Referrer-Policy', 'strict-origin-when-cross-origin');
  response.headers.set('X-Frame-Options', 'DENY');

  return response;
}

function buildCspHeader(nonce: string): string {
  const directives = [
    "default-src 'self'",
    `script-src 'nonce-${nonce}' 'strict-dynamic'`,
    "style-src 'self' 'unsafe-inline'",
    "img-src 'self' data: https:",
    "font-src 'self' https://fonts.gstatic.com",
    "connect-src 'self' https://*.supabase.co https://*.stripe.com https://*.sentry.io",
    "frame-src 'self' https://*.stripe.com",
    "object-src 'none'",
    "base-uri 'self'",
    "form-action 'self'",
    "frame-ancestors 'none'",
    // Optional: report violations to a monitoring endpoint
    // "report-uri /api/csp-report",
  ];

  return directives.join('; ');
}

Step 2: Read the nonce in layout.tsx

The layout reads the nonce from the custom request header and passes it to every Script component and inline script that needs it:

// app/layout.tsx
import { headers } from 'next/headers';
import Script from 'next/script';

export default async function RootLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  const headersList = await headers();
  const nonce = headersList.get('x-nonce') ?? '';

  return (
    <html lang="en">
      <head>
        {/* Stripe.js — nonce allows it to load */}
        <Script
          src="https://js.stripe.com/v3/"
          nonce={nonce}
          strategy="beforeInteractive"
        />
        {/* Sentry — 'strict-dynamic' lets Stripe/Sentry load their own sub-scripts */}
        <Script
          src="https://browser.sentry-cdn.com/8.x/bundle.min.js"
          nonce={nonce}
          strategy="beforeInteractive"
        />
      </head>
      <body>
        {children}
        {/* Inline script example — must carry the nonce */}
        <Script nonce={nonce} id="theme-init">
          {`document.documentElement.dataset.theme =
            localStorage.getItem('theme') || 'light';`}
        </Script>
      </body>
    </html>
  );
}

Step 3: Pass nonce to client components that render scripts

If any client component dynamically inserts scripts (analytics events, chat widgets), you need to thread the nonce down via React context or props:

// lib/nonce-context.tsx
'use client';
import { createContext, useContext } from 'react';

const NonceContext = createContext<string>('');

export function NonceProvider({
  nonce,
  children,
}: {
  nonce: string;
  children: React.ReactNode;
}) {
  return (
    <NonceContext.Provider value={nonce}>
      {children}
    </NonceContext.Provider>
  );
}

export function useNonce() {
  return useContext(NonceContext);
}

Then wrap your layout body with <NonceProvider nonce={nonce}> and call useNonce() in any client component that needs to create script elements. This is the part most tutorials skip — and the part that causes CSP violations in production when a chat widget or analytics component renders a script tag without the nonce.

What does each CSP directive do and why is it needed?

CSP headers are a semicolon-separated list of directives. Each directive controls a specific resource type. Here is what each directive in the configuration above does, and why it is set the way it is:

Directive	Value	Purpose
`default-src`	`'self'`	Fallback for all resource types not explicitly listed. Restricts to same origin.
`script-src`	`'nonce-{value}' 'strict-dynamic'`	Only scripts with the matching nonce can execute. `strict-dynamic` allows those scripts to load additional scripts (Stripe.js loads sub-modules).
`style-src`	`'self' 'unsafe-inline'`	Allows same-origin stylesheets and inline styles. Most CSS-in-JS frameworks (Tailwind, styled-components) require `unsafe-inline` for styles. Nonce-based styles are possible but break hot reload in dev.
`img-src`	`'self' data: https:`	Allows images from same origin, data URIs (Base64-encoded thumbnails), and any HTTPS source (CDN images, user avatars).
`connect-src`	`'self' https://*.supabase.co ...`	Controls fetch, XMLHttpRequest, WebSocket. Must include every API domain your app calls.
`frame-src`	`'self' https://*.stripe.com`	Controls iframes. Stripe Elements uses iframes for PCI compliance.
`object-src`	`'none'`	Blocks Flash, Java applets, and other plugin-based content. No legitimate use in modern web apps.
`base-uri`	`'self'`	Prevents attackers from changing the base URL to redirect relative links.
`frame-ancestors`	`'none'`	Prevents your site from being embedded in iframes (clickjacking protection). Replaces X-Frame-Options.

The critical insight: 'strict-dynamic' is what makes nonce-based CSP compatible with third-party scripts. Without it, every sub-script loaded by Stripe or Sentry would need its own nonce — which is impossible since you do not control their source code. With 'strict-dynamic', any script loaded by a nonce-bearing script inherits trust. According to the W3C CSP Level 3 specification, 'strict-dynamic' causes the browser to ignore allowlist-based entries in script-src and trust only nonces, hashes, and dynamically created scripts.

How do the four CSP approaches compare?

Approach	XSS Protection	Third-Party Compat	Implementation Effort	Next.js 16 Support
No CSP	None	Full (no restrictions)	Zero	N/A
Meta tag CSP	Partial (no report-uri, limited directives)	Medium (static, same nonce every page load)	Low (one <meta> tag)	Yes
Middleware CSP (Next.js 15)	Strong (per-request nonce)	High (strict-dynamic)	Medium (middleware + header threading)	No (build fails)
proxy.ts CSP (Next.js 16)	Strong (per-request nonce)	High (strict-dynamic)	Medium (proxy + header threading)	Yes (recommended)

When to use each: If you are on Next.js 16, proxy.ts CSP is the only viable nonce-based option. Meta tag CSP is acceptable for static sites with no inline scripts. No CSP is a security risk in any application handling user data — and a compliance failure for PCI DSS, SOC 2, or HIPAA scopes.

What are the three most common CSP mistakes?

Mistake 1: Using a static nonce

A nonce must be unique per request. If you hardcode a nonce value or generate it once at build time and reuse it across all responses, you have effectively created an allowlist with extra steps. An attacker who observes one response learns the nonce and can inject scripts carrying it.

Wrong: const nonce = 'abc123'; (static, reused across requests)
Right: const nonce = Buffer.from(crypto.randomUUID()).toString('base64'); (unique per request)

I have seen this mistake in 4 out of 7 open-source Next.js CSP implementations I reviewed. The nonce works in testing (because the same browser sees the same nonce) but provides zero security benefit in production.

Mistake 2: Forgetting the nonce on dynamically inserted scripts

Your CSP is only as strong as the weakest script tag. If your layout has proper nonces but a client component uses document.createElement('script') without the nonce, that script is blocked and the feature breaks silently. Common culprits:

Analytics snippets (Google Analytics, Mixpanel) that inject scripts on page load
Chat widgets (Intercom, Crisp) that dynamically create script elements
A/B testing tools (Optimizely, LaunchDarkly) that inject variation scripts
Cookie consent banners that conditionally load tracking scripts

The fix for each: use the useNonce() context hook shown above, and set script.nonce = nonce before appending the element to the DOM. If the third-party SDK does not support nonces (many do not), you need to add its domain to script-src alongside the nonce — but 'strict-dynamic' will handle its sub-scripts.

Mistake 3: CSP breaking third-party scripts without clear errors

When CSP blocks a script, the browser logs a violation in the console but the script fails silently from the application's perspective. Stripe Elements stops rendering. Sentry stops capturing errors. Your scheduling widget disappears. Users see a broken UI with no error message.

The debugging process I follow:

Open browser DevTools, go to the Console tab
Look for Refused to execute inline script or Refused to load the script messages
Each violation message includes the blocked URI and the directive that blocked it
Add the domain to the appropriate directive (connect-src for API calls, frame-src for iframes, script-src for scripts)

// Example browser console output when CSP blocks a script:
Refused to load the script 'https://widget.intercom.io/widget/abc123'
because it violates the following Content Security Policy directive:
"script-src 'nonce-dGhpcyBpcyBhIHRlc3Q=' 'strict-dynamic'".

// Fix: add Intercom's domain to connect-src (for API calls)
// and ensure the initial script tag carries the nonce

How do you test that CSP is working correctly?

Testing CSP requires verifying both that legitimate scripts execute and that illegitimate scripts are blocked. Here is the testing sequence I use:

Test 1: Verify the header exists

# Check CSP header on the response
curl -s -D - https://your-app.vercel.app/ | grep -i "content-security-policy"

# Expected output (single line, semicolon-separated directives):
# content-security-policy: default-src 'self'; script-src 'nonce-abc123...' 'strict-dynamic'; ...

Test 2: Verify the nonce changes per request

# Run twice and compare nonces
NONCE1=$(curl -s -D - https://your-app.vercel.app/ | grep -oP "nonce-[A-Za-z0-9+/=]+")
NONCE2=$(curl -s -D - https://your-app.vercel.app/ | grep -oP "nonce-[A-Za-z0-9+/=]+")
echo "Nonce 1: $NONCE1"
echo "Nonce 2: $NONCE2"
# These MUST be different. If they are the same, you have a static nonce bug.

Test 3: Verify blocked scripts in the browser

Open DevTools, paste this into the Console, and confirm it is blocked:

// This should be blocked by CSP (no nonce on the injected script)
const s = document.createElement('script');
s.textContent = 'console.log("CSP bypass attempt")';
document.head.appendChild(s);

// Expected: "Refused to execute inline script" in console
// If this runs successfully, your CSP is not working.

Test 4: Set up violation reporting

For ongoing monitoring, add a report-uri directive pointing to an API route that logs violations:

// app/api/csp-report/route.ts
import { NextRequest, NextResponse } from 'next/server';

export async function POST(request: NextRequest) {
  const body = await request.json();
  // Log to your monitoring system (Sentry, Datadog, etc.)
  console.warn('CSP Violation:', JSON.stringify(body['csp-report'], null, 2));
  return NextResponse.json({ received: true });
}

In production, I route CSP violation reports to Sentry. Over the first week after deploying nonce-based CSP, we received 247 violation reports — 241 were browser extensions injecting scripts (expected and harmless), 4 were legitimate third-party scripts we had missed in our connect-src directive, and 2 were our own inline scripts missing nonces. The violation reports found bugs we would not have caught in manual testing.

What does the full migration checklist look like?

If you are migrating from Next.js 15 middleware-based CSP to Next.js 16 proxy-based CSP, here is the step-by-step process I followed:

Audit your middleware.ts — identify every header manipulation, redirect, and rewrite. CSP is usually one of several concerns in middleware.
Move CSP logic to proxy.ts — use the buildCspHeader() pattern shown above. Keep the nonce generation identical (both use crypto.randomUUID()).
Move non-CSP middleware logic — auth session refresh moves to proxy.ts (if using Supabase, updateSession() already lives there). Redirects move to next.config.ts rewrites/redirects where possible.
Delete middleware.ts — the build will fail if both files exist. Do not rename it; delete it.
Create NonceProvider context — thread the nonce to client components that dynamically create scripts.
Audit every Script component — search for <Script and <script across your codebase. Every instance must have nonce={nonce}.
Test third-party integrations — load each page that uses Stripe, Sentry, analytics, or chat widgets. Check the console for CSP violations.
Deploy to staging first — CSP issues are invisible in server logs. They only appear in the browser. Test every user flow in staging before promoting to production.

Timing note: The migration took me approximately 3 hours for a production app with 189 routes, Stripe integration, Sentry error tracking, and a calendar scheduling widget. The most time-consuming part was step 7 — testing third-party scripts — which required loading 12 different pages and checking the console on each one. The proxy.ts code change itself took 20 minutes.

What about style-src and unsafe-inline?

You may notice that the configuration above uses 'unsafe-inline' for styles but not for scripts. This is intentional. Nonce-based styles are technically possible, but in practice they break most CSS-in-JS solutions and dev-mode hot reload. Tailwind CSS, which compiles to static stylesheets, works fine with 'self' alone — but any runtime style injection (styled-components, Emotion, MUI) requires either 'unsafe-inline' or a nonce on every injected style tag.

The security tradeoff is acceptable: CSS-based attacks (CSS injection, data exfiltration via background-image URLs) are significantly less dangerous than script-based XSS. According to the OWASP CSP Cheat Sheet, 'unsafe-inline' for styles is considered an acceptable compromise when nonce-based script-src is in place. The priority order is: eliminate 'unsafe-inline' for scripts first, then address styles if your framework supports it.

Frequently Asked Questions

Can I use CSP with next/head instead of proxy.ts?

You can set a meta-tag CSP via <meta http-equiv="Content-Security-Policy"> in a Head component, but it has significant limitations. Meta-tag CSP does not support report-uri, frame-ancestors, or sandbox directives. It also cannot be used with nonces in a meaningful way because the meta tag is part of the static HTML — the nonce value would be the same for every cached page. For production applications, HTTP-header-based CSP via proxy.ts is the correct approach.

Does strict-dynamic work in all browsers?

As of April 2026, 'strict-dynamic' is supported in Chrome 52+, Firefox 52+, Safari 15.4+, and Edge 79+. This covers approximately 96% of global browser traffic according to Can I Use. The main gap is older Safari versions on iOS 14 and below, which represent less than 1.5% of traffic. For unsupported browsers, 'strict-dynamic' is ignored and the browser falls back to evaluating the rest of the script-src directive.

How do I handle CSP in development mode?

Next.js dev mode injects inline scripts for hot reload, error overlays, and React refresh. These scripts will not have your nonce. The simplest approach: conditionally skip CSP in development by checking process.env.NODE_ENV in your proxy.ts. Do not weaken your CSP for dev — skip it entirely. A weakened dev CSP gives false confidence that third-party scripts work when they may not work under the production policy.

What happens if the nonce header is missing in layout.tsx?

If headers().get('x-nonce') returns null, your Script components render without a nonce attribute. The browser then checks them against the CSP policy, finds no matching nonce, and blocks them. The result: a blank page or broken functionality with CSP violation messages in the console. Always provide a fallback empty string (?? '') and log a warning if the nonce is missing in production.

Should I use Content-Security-Policy-Report-Only first?

Yes. Deploy with Content-Security-Policy-Report-Only header first. This reports violations without blocking anything. Run it in production for 48-72 hours, review the violation reports, fix any legitimate scripts that would be blocked, then switch to the enforcing Content-Security-Policy header. This two-phase deployment prevented 4 third-party breakages in my case that I would have shipped to users without the report-only phase.

Dinesh Challa is an AI Product Manager building production software with Claude Code. Follow him on LinkedIn.

Published April 11, 2026. Part of a series on Next.js + Supabase + AI production patterns, covering security hardening for applications handling PII.