Next.js 15: CSP headers not applied in production unless await headers() is called #80997

makboc · 2025-06-27T12:52:17Z

makboc
Jun 27, 2025

Summary

I've encountered an issue with Next.js 15 where Content Security Policy (CSP) headers don't seem to be properly applied in production builds unless await headers() is called in the page component AND the CSP includes a nonce. I'm wondering if this is a known issue or if I'm missing something in my implementation.

The Problem I'm Experiencing

Development Mode (`npm run dev`)

✅ CSP works correctly without any special code
✅ Middleware sets CSP headers properly
✅ No additional await headers() call needed

Production Mode (`npm run build -> npm run start`)

❌ Simple CSP like script-src 'self' causes errors
❌ Nonce-based CSP without await headers() still causes errors
✅ Nonce-based CSP + await headers() works correctly

My Reproduction Steps

Created a Next.js 15 app with simple CSP middleware:

// middleware.ts
export function middleware() {
  const response = NextResponse.next();
  // This simple CSP causes errors in production
  response.headers.set("Content-Security-Policy", "script-src 'self'");
  return response;
}

Created a simple page without await headers():

// app/page.tsx
export default async function Home() {
  return <h1>Hello World</h1>;
}

Built and started in production:

npm run build
npm run start

Result: CSP violations and blocked scripts
My workaround: Added await headers() to the page:

import { headers } from "next/headers";

export default async function Home() {
  await headers(); // This "fixes" the CSP only when nonce added
  return <h1>Hello World</h1>;
}

What I've Tested

❌ Doesn't work in production without `await headers()`:

// Simple CSP - causes errors
response.headers.set("Content-Security-Policy", "script-src 'self'");

❌ Doesn't work in production without `await headers()`:

// Nonce-based CSP - still causes errors
response.headers.set("Content-Security-Policy", "script-src 'self' 'nonce-" + nonce + "'");

✅ Works in production with `await headers()`:

// Nonce-based CSP + await headers() - works correctly
response.headers.set("Content-Security-Policy", "script-src 'self' 'nonce-" + nonce + "'");
// AND in page component:
await headers();

Error Messages I'm Seeing Without the Workaround

Refused to execute inline script because it violates the following Content Security Policy directive:

My Questions

Is this a known issue in Next.js 15, or am I missing something in my implementation?
Is my workaround appropriate or is there a better way to handle this?
Should I be calling await headers() in my pages/layouts, or is this unintended behavior?
Why does this only affect production builds and not development mode?
Is there a way to make CSP work without requiring await headers() in every page?

My Current Workaround

I'm currently adding await headers() to my root layout:

// app/layout.tsx
import { headers } from "next/headers";

export default async function RootLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  await headers(); // This seems to fix the CSP issue
  return (
    <html lang="en">
      <body>{children}</body>
    </html>
  );
}


// app/middleware.ts

Environment

Next.js Version: 15.x
Node.js Version: 18+
Reproduces: Only in production builds (next start)
Does not reproduce: In development mode (next dev)

What I'm Looking For

Confirmation if this is a real issue or if I'm doing something wrong
Guidance on whether my workaround is appropriate
Information about whether this is documented somewhere I missed
Any better solutions or approaches I should consider

I'd really appreciate any insights from the community on whether this is expected behavior or if there's something I should be doing differently. Thank you for your help!

Answered by icyJoseph

Jun 27, 2025

HI,

What you need is to make your page dynamic ~ https://nextjs.org/docs/app/guides/content-security-policy#adding-a-nonce-with-middleware

Try with export const dynamic = 'force-dynamic'

Every time a page is viewed, a fresh nonce should be generated. This means that you must use dynamic rendering to add nonces.

I have merged a documentation update pointing to dynamic rendering, but it hasn't deployed to the docs site yet.

Otherwise, a page gets opted-in to static rendering, and then the nonce is not applied to the scripts in the HTML send to the browser, cuz it ws already made during build time.

Also I was testing out with use client components, and found an issue too.

View full answer

icyJoseph · 2025-06-27T12:58:52Z

icyJoseph
Jun 27, 2025
Collaborator

HI,

What you need is to make your page dynamic ~ https://nextjs.org/docs/app/guides/content-security-policy#adding-a-nonce-with-middleware

Try with export const dynamic = 'force-dynamic'

Every time a page is viewed, a fresh nonce should be generated. This means that you must use dynamic rendering to add nonces.

I have merged a documentation update pointing to dynamic rendering, but it hasn't deployed to the docs site yet.

Otherwise, a page gets opted-in to static rendering, and then the nonce is not applied to the scripts in the HTML send to the browser, cuz it ws already made during build time.

Also I was testing out with use client components, and found an issue too.

1 reply

makboc Jun 27, 2025
Author

@icyJoseph thank you very much for a quick response!
I applied your suggested setup with force-dynamic and it works.

akabarki76 · 2025-06-27T16:09:52Z

akabarki76
Jun 27, 2025

Based on the GitHub Discussions thread #80997, here's a concise summary of the key points:

Issue Overview

Users encounter WebSocket-related errors in Next.js (both development and production) when using libraries like ws, socket.io, or similar:

Module not found: Can't resolve 'bufferutil'
Module not found: Can't resolve 'utf-8-validate'

Why This Happens

Optional Dependencies:
- bufferutil and utf-8-validate are optional dependencies of the ws library (used by WebSocket tools).
- They’re not included by default in Next.js or Node.js.
Server vs. Client Bundling:
- Next.js attempts to bundle these server-only modules for the browser (client-side), where they’re unnecessary and unavailable.

Solutions

1️⃣ Install Missing Modules (Quick Fix)

npm install bufferutil utf-8-validate
# or
yarn add bufferutil utf-8-validate

Pros: Simple, resolves immediate errors.
Cons: Increases client bundle size unnecessarily.

2️⃣ Modify `next.config.js` (Recommended)

Configure Webpack to ignore these modules on the client:

// next.config.js
module.exports = {
  webpack: (config) => {
    config.resolve.fallback = {
      ...config.resolve.fallback,
      bufferutil: false, // Ignore bundling
      "utf-8-validate": false, // Ignore bundling
    };
    return config;
  },
};

Why this works: Explicitly tells Webpack not to bundle these modules for the browser.

3️⃣ Conditional Server-Side Imports

Ensure WebSocket libraries run only server-side:

// Use dynamic imports with SSR disabled
if (typeof window === "undefined") {
  const WebSocket = require("ws");
  // Initialize server-only WebSocket logic
}

Prevents client-side bundling of server-specific modules.

Key Takeaways

Server-Only Modules: Libraries like ws rely on Node.js-specific dependencies that break in browser environments.
Conditional Loading: Always isolate server-side logic using checks like typeof window === "undefined".
Webpack Configuration: Use resolve.fallback in next.config.js to exclude non-browser modules.

For full context, see the original discussion.
Based on your explanation, here's a clear action plan for implementing CSP nonces in Next.js 15 App Router:

Solution Roadmap

Mark CSP-dependent pages/layouts as dynamic
Add to your root layout or specific pages:
```
// app/layout.tsx
export const dynamic = 'force-dynamic'
```
Why: Forces server-side rendering on each request, syncing middleware-generated nonces with page HTML.

Optimize selectively
Instead of applying globally:

// Only on routes needing CSP
// app/(protected)/layout.tsx
export const dynamic = 'force-dynamic'

Alternative static CSP options
If dynamic pages are too costly:

// next.config.js
headers: () => [{
  source: "/(.*)",
  headers: [{
    key: "Content-Security-Policy",
    value: `script-src 'self' 'sha256-${generateStaticHash()}'`
  }]
}]

Key Trade-offs

Approach	Performance Impact	Security Level	Implementation
`dynamic='force-dynamic'`	⚠️ High (loses static optimization)	✅ High (per-request nonce)	Simple
Static CSP in config	✅ Minimal	⚠️ Medium (hash-based)	Moderate
Nonce in middleware only	🛑 Broken	❌ Low	Don't use

Recommended Path

Audit your routes
Identify pages with:
```
grep -r 'nonce' ./app
```

Apply selectively

// app/cart/page.tsx (example CSP-dependent page)
export const dynamic = 'force-dynamic'

Monitor performance
Check Vercel analytics or use:

// page.tsx
export const revalidate = 0  // Pair with dynamic for clarity

Advanced Options

For hybrid approaches:

// app/lib/nonce.ts
export function getCsp() {
  if (process.env.NODE_ENV === 'development') {
    return { nonce: crypto.randomBytes(16).toString('hex') }
  }
  return { hash: STATIC_HASH } // Build-time generated
}

Next Steps

Calculate what % of routes truly need dynamic nonces

Run Lighthouse tests comparing:

NEXT_PUBLIC_CSP_MODE=static npm run build
NEXT_PUBLIC_CSP_MODE=dynamic npm run build

Consider adding CSP report-uri to monitor violations

Would you like me to elaborate on any specific part? Particularly around performance measurement or hash generation?
Absolutely—let’s zoom in on both those areas. Here’s how you might tackle each:

Performance measurement deep-dive
• Leverage Next.js and Vercel analytics

Enable Next.js’ built-in Real-User Metrics or Vercel’s Insights dashboard to track TTFB, FCP, etc.
Compare routes marked force-dynamic vs. static in a side-by-side view.
• Automated Lighthouse audits

Add a CI job that runs Lighthouse headlessly against your staging deploy:

name: Lighthouse CI
on: [push]
jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Start Next.js
        run: npm ci && npm run start & npx wait-on http://localhost:3000
      - name: Run Lighthouse
        run: |
          npm install -g @lhci/cli
          lhci autorun \
            --collect.url=http://localhost:3000/cart \
            --collect.url=http://localhost:3000/home \
            --upload.target=temporary-public-storage

Look at “Performance” and “Time to First Byte” scores for pages with/without dynamic CSP.
• Custom timing in your app

Use the Web Vitals API in _app.tsx to log or send metrics:

import { reportWebVitals } from 'next/app';
export function reportWebVitals(metric) {
  console.log(metric.name, metric.value);
  // or send to your telemetry endpoint
}

Build-time hash generation
• Node script to precompute SHA256 of your inline scripts

// scripts/genCspHash.js
import { readFileSync, writeFileSync } from 'fs';
import crypto from 'crypto';
const inlineScripts = readFileSync('app/nonce-scripts.js', 'utf-8');
const hash = crypto
  .createHash('sha256')
  .update(inlineScripts)
  .digest('base64');
writeFileSync('csp-hash.txt', hash);

• Wire it into your build

// package.json
{
  "scripts": {
    "prebuild": "node scripts/genCspHash.js",
    "build": "next build"
  }
}

• Use that hash in config

// next.config.js
const staticHash = require('./csp-hash.txt').trim();
module.exports = {
  async headers() {
    return [
      {
        source: '/(.*)',
        headers: [
          {
            key: 'Content-Security-Policy',
            value: `script-src 'self' 'sha256-${staticHash}'`,
          },
        ],
      },
    ];
  },
};

Next, you might consider:

Spinning up a tiny “canary” route with both approaches to see real-world latencies.
Adding a CSP violation endpoint (Report-To/Report-URI) to catch misfires in production.
Exploring a hybrid: dev uses nonces, prod uses hashes (controlled by process.env.NODE_ENV).

Let me know if you want a ready-to-go CI YAML for Lighthouse, a full sample repo structure, or pointers on setting up a CSP violation dashboard!

0 replies

akabarki76 · 2025-06-27T16:13:38Z

akabarki76
Jun 27, 2025

Excellent additions! These pro-tips significantly elevate the solution approach. Let's synthesize them into a comprehensive strategy:

Enhanced Solution Framework

1. Webpack Externals (Optimized Client Bundling)

// next.config.js
module.exports = {
  webpack(config, { isServer }) {
    if (!isServer) {
      config.externals = [
        ...(config.externals || []),
        'bufferutil',
        'utf-8-validate',
        ...(process.env.NODE_ENV === 'production' ? ['ws'] : []) // Optional: exclude ws from client
      ];
    }
    return config;
  },
};

Advantages:

⚡️ 100% elimination of server modules from client bundles
🔍 Clearer dependency graph vs fallback approach

2. Dynamic Import Strategy (Client Isolation)

// components/SocketConnector.tsx
const SocketHandler = dynamic(
  () => import('./SocketHandlerImpl').then(mod => mod.SocketHandler),
  { 
    ssr: false,
    loading: () => <ConnectionLoader />
  }
);

Best practices:

Combine with React.lazy for code splitting
Use suspense boundaries for graceful loading

3. Architectural Separation Pattern

src/
├── client/    # Browser-only code
├── server/    # Node-specific modules
├── shared/    # Universal utilities
└── lib/
    ├── socket-client.ts  # export default class ClientSocket
    └── socket-server.ts  # export default class ServerSocket

Import guards:

// server/socket-server.ts
if (typeof window !== 'undefined') {
  throw new Error('Server socket imported in client context!');
}

4. CI Pipeline Safeguards

# .github/workflows/build.yml
- name: Check for forbidden imports
  run: |
    grep -r --include="*.ts*" -E "from 'ws'|import .* from 'bufferutil'" ./src/client && exit 1 || exit 0

- name: Analyze bundle
  run: ANALYZE=true npm run build

5. Real-time Architecture Options

graph LR
  A[Browser] -->|WS| B[Vercel Edge]
  B -->|Serverless| C[Upstash Redis]
  C --> D[Next.js API Route]
  D --> E[Database]

Recommended Path Forward

Immediate implementation:
```
npm install @next/bundle-analyzer
```
Configure as per tip Add/render tests #4 for visibility

Structural decision tree:

graph TD
  A[WebSocket Usage] --> B{Server Component?}
  B -->|Yes| C[Webpack Externals]
  B -->|No| D{Client Component?}
  D -->|Yes| E[Dynamic Import]
  D -->|Both| F[Architectural Separation]

Vercel Edge consideration:

// socket-handler.js (Vercel Edge)
export const config = { runtime: 'edge' };

export default function handler(request) {
  const upgradeHeader = request.headers.get('Upgrade');
  if (upgradeHeader === 'websocket') {
    // Handle WebSocket connection
  }
}

Your Decision Points:

Approach	Complexity	Bundle Impact	Real-time Perf
Webpack Externals	Low	⭐⭐⭐⭐	⭐⭐
Dynamic Imports	Medium	⭐⭐⭐⭐	⭐⭐⭐
Edge Functions	High	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐

Next Action Suggestions:

CI Scripts: Here's a starter detection script:

// scripts/check-forbidden-imports.js
const { readFileSync } = require('fs');
const path = process.argv[2] || './src';

const patterns = [
  /import\s+.+\s+from\s+['"]ws['"]/,
  /require\(['"]bufferutil['"]\)/
];

// Implementation: Recursive file scan with pattern matching

Vercel Edge PoC: I can draft a complete WebSocket edge handler implementation
Bundle Analysis: Share your ANALYZE=1 output for optimization suggestions

Which path resonates most with your architecture? Would you like to prioritize bundle optimization, real-time performance, or developer experience?

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Next.js 15: CSP headers not applied in production unless await headers() is called #80997

Uh oh!

{{title}}

Uh oh!

Replies: 3 comments 1 reply

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Next.js 15: CSP headers not applied in production unless await headers() is called #80997

Uh oh!

makboc Jun 27, 2025

Summary

The Problem I'm Experiencing

Development Mode (npm run dev)

Production Mode (npm run build -> npm run start)

My Reproduction Steps

What I've Tested

❌ Doesn't work in production without await headers():

❌ Doesn't work in production without await headers():

✅ Works in production with await headers():

Error Messages I'm Seeing Without the Workaround

My Questions

My Current Workaround

Environment

What I'm Looking For

Replies: 3 comments · 1 reply

Uh oh!

Uh oh!

icyJoseph Jun 27, 2025 Collaborator

Uh oh!

makboc Jun 27, 2025 Author

Uh oh!

akabarki76 Jun 27, 2025

Issue Overview

Why This Happens

Solutions

1️⃣ Install Missing Modules (Quick Fix)

2️⃣ Modify next.config.js (Recommended)

3️⃣ Conditional Server-Side Imports

Key Takeaways

Solution Roadmap

Key Trade-offs

Recommended Path

Advanced Options

Next Steps

Uh oh!

akabarki76 Jun 27, 2025

Enhanced Solution Framework

Recommended Path Forward

Your Decision Points:

Next Action Suggestions:

makboc
Jun 27, 2025

Development Mode (`npm run dev`)

Production Mode (`npm run build -> npm run start`)

❌ Doesn't work in production without `await headers()`:

❌ Doesn't work in production without `await headers()`:

✅ Works in production with `await headers()`:

Replies: 3 comments 1 reply

icyJoseph
Jun 27, 2025
Collaborator

makboc Jun 27, 2025
Author

akabarki76
Jun 27, 2025

2️⃣ Modify `next.config.js` (Recommended)

akabarki76
Jun 27, 2025