Next.js 16 CSP — Missing script-src Allowed XSS Through a Third-Party Widget

Security in Next.js 16 is a layered defense: Content Security Policy (CSP) controls what scripts and resources the browser can load, the Taint API prevents accidental data exposure to client components, Server Actions enforce origin-based access control, and React’s built-in sanitization handles most XSS vectors in JSX. But these layers only work if they’re configured correctly.

We learned this when a penetration test revealed that our Content-Security-Policy was missing the script-src directive. This meant the browser would allow any script to execute — including a malicious payload embedded in a third-party chatbot widget that exfiltrated session cookies to an attacker-controlled server. The widget was legitimate, but it dynamically loaded JavaScript from a CDN that an attacker had compromised.

The fix required: adding script-src with specific hash-based allowlisting for inline scripts, enabling the Taint API to prevent server data leaks, and configuring Server Actions with proper input validation. This article covers all three defense layers with production code examples and deployment guidance.

CSP — Why default-src Is Not a Security Blanket

Content-Security-Policy is the browser’s instruction manual for what resources are allowed to load on your page. The default-src directive serves as a fallback for any directive that is NOT explicitly set. Many developers set default-src 'self' and assume all resource types are restricted. This is incorrect.

When script-src is omitted, the browser uses default-src for scripts but with a critical caveat: default-src does not control inline script execution. Inline scripts and event handlers are controlled exclusively by script-src. Without an explicit script-src, browsers default to allowing inline scripts.

The correct approach: always declare script-src explicitly. Use 'strict-dynamic' for hash-based or nonce-based allowlisting of inline scripts, and specify exact origins for third-party script sources.

script-src 'self' 'unsafe-eval' 'strict-dynamic'
  'sha256-abc123def456='
  'sha256-789ghi012jkl='
  https://chatbot.example.com;

Hash-Based Script Allowlisting — How to Generate and Manage Script Hashes

Hash-based allowlisting requires generating a SHA-256 hash of every inline script in your application and adding it to the script-src directive. The hash changes when the script content changes, so any tampering produces a different hash and the browser blocks execution.

To generate hashes: extract every inline <script> tag from your production HTML, compute its SHA-256 hash using openssl dgst -sha256 -binary | base64, and add 'sha256-<hash>' to your script-src. For Next.js, inline scripts include the bootstrap runtime, analytics snippets, and embedded data.

The challenge: Next.js adds inline scripts dynamically during build. Each deployment may have different hashes. Solution: use 'strict-dynamic' or generate hashes as part of your CI pipeline.

for html_file in $(find .next/server -name '*.html'); do
  grep -oP '<script>.*?</script>' "$html_file" | while read -r script; do
    content=$(echo "$script" | sed 's/<script>//;s/<\/script>//')
    hash=$(echo -n "$content" | openssl dgst -sha256 -binary | base64)
    echo "'sha256-$hash'"
  done
done | sort -u

The Taint API — Preventing Accidental Data Exposure

The Taint API is React 19’s mechanism for preventing sensitive server data from reaching client components. When you taint an object reference or value, any attempt to pass it to a 'use client' component throws an error in development and silently strips the data in production.

This is the solution to the most common Next.js data leak: a server component fetches user data with API keys or PII, then passes it as a prop to a client component. The data gets serialized in the HTML response and becomes visible in the page source. The Taint API catches this at compile time.

The API works at the object reference level: taintObjectReference(message, object) marks a specific object instance. taintUniqueValue is for primitive values like strings and numbers.

import { experimental_taintObjectReference } from 'react';

export async function getUserData(userId: string) {
  const user = await db.user.findUnique({ where: { id: userId } });
  experimental_taintObjectReference(
    'Do not pass user data to client components', user
  );
  return { id: user.id, name: user.name, avatar: user.avatar };
}

Server Actions Security Model — What They Protect and What They Don’t

Server Actions in Next.js 16 have a built-in security model: they are only accessible from the same origin by default. Cross-origin requests are rejected with a 403 Forbidden response. This prevents external websites from calling your server actions directly.

However, Server Actions do NOT validate input by default. If a Server Action expects a userId parameter, a malicious user can pass any user ID. Server Actions are essentially POST endpoints — you must add your own authorization checks, input validation, and rate limiting.

The common mistake: treating Server Actions as secure by default because they’re not exposed as REST endpoints. They ARE exposed as POST requests to internal endpoints. The origin check prevents CSRF but does not prevent a logged-in user from calling any action with any parameters.

'use server';
import { z } from 'zod';

const orderSchema = z.object({
  productId: z.string().uuid(),
  quantity: z.number().int().min(1).max(10),
});

export async function submitOrder(formData: FormData) {
  const session = await auth();
  if (!session?.user) throw new Error('Unauthorized');

  const parsed = orderSchema.safeParse({
    productId: formData.get('productId'),
    quantity: Number(formData.get('quantity')),
  });
  if (!parsed.success) throw new Error('Invalid input');

  return createOrder(session.user.id, parsed.data);
}

XSS Prevention in JSX — React’s Built-In Defenses and Their Limits

React’s JSX automatically escapes string values, preventing the most common XSS vector: injecting HTML via string interpolation. If a user types <script>alert(1)</script> into a rendered expression, React escapes the tags and displays the literal string.

However, there are XSS vectors that React does not protect against: dangerouslySetInnerHTML (bypasses escaping), href attributes with javascript: URLs, and server-side injection via __NEXT_DATA__. The __NEXT_DATA__ concern: Next.js serializes all props into a <script> tag. If any prop contains unsanitized user-generated content, it is serialized into the page source.

import DOMPurify from 'isomorphic-dompurify';

export function SanitizedHTML({ html }: { html: string }) {
  const clean = DOMPurify.sanitize(html, {
    ALLOWED_TAGS: ['p', 'b', 'i', 'em', 'strong', 'a', 'ul', 'ol', 'li', 'br'],
    ALLOWED_ATTR: ['href', 'target', 'rel'],
  });
  return <div dangerouslySetInnerHTML={{ __html: clean }} />;
}

CSRF Protection in Next.js 16 — Built-In vs Manual

Next.js 16 provides built-in CSRF protection for Server Actions through the SameSite cookie attribute (default Lax) and the origin check. When a Server Action receives a request, it verifies the Origin or Referer header matches the deployment origin.

For API routes (Route Handlers), you must implement CSRF protection yourself. The standard approach: use a CSRF token pattern where the server generates a token, includes it in the response, and validates it on subsequent state-changing requests.

For forms using Server Actions, the built-in protection is usually sufficient. For API routes consumed by mobile apps or third-party services, implement token-based authentication instead.

import { cookies } from 'next/headers';
import crypto from 'crypto';

export async function generateCsrfToken(): Promise<string> {
  const token = crypto.randomUUID();
  const cookieStore = await cookies();
  cookieStore.set('csrf-token', token, {
    httpOnly: true, sameSite: 'strict', secure: true, path: '/',
  });
  return token;
}

export async function validateCsrfToken(token: string): Promise<boolean> {
  const cookieStore = await cookies();
  return cookieStore.get('csrf-token')?.value === token;
}

Rate Limiting Server Actions and API Routes

Rate limiting is essential for any public-facing endpoint, including Server Actions. Without rate limiting, a malicious user can call a Server Action thousands of times per second, exhausting resources.

The challenge: each Server Action is a separate endpoint, so rate limiting must be applied at the action level. Use a distributed rate limiter (Redis-based) for multi-instance deployments.

import { Ratelimit } from '@upstash/ratelimit';

export const rateLimit = new Ratelimit({
  limiter: Ratelimit.slidingWindow(10, '10 s'),
});

// In your Server Action:
// const { success } = await rateLimit.limit(`action:${userId}`);
// if (!success) throw new Error('Rate limit exceeded');

Environment Variables and Secrets — The NEXT_PUBLIC Trap

Secret management has a critical pitfall: NEXT_PUBLIC_* environment variables are baked into the client-side bundle at build time. Any value with this prefix becomes visible in the browser’s JavaScript source.

The rule: never put a secret in a NEXT_PUBLIC_* variable. Use server-only environment variables (without the prefix) and access them via process.env in server components and route handlers.

export const serverConfig = {
  databaseUrl: process.env.DATABASE_URL,
  stripeSecretKey: process.env.STRIPE_SECRET_KEY,
  jwtSecret: process.env.JWT_SECRET,
} as const;

for (const key of ['DATABASE_URL', 'STRIPE_SECRET_KEY', 'JWT_SECRET']) {
  if (!process.env[key]) throw new Error(`Missing: ${key}`);
}

Security Headers Beyond CSP — The Complete Suite

Content-Security-Policy is the most important security header, but it should not be the only one. A complete suite includes: Strict-Transport-Security (HTTPS enforcement), X-Frame-Options (clickjacking prevention), X-Content-Type-Options (MIME sniffing prevention), Referrer-Policy (referrer control), and Permissions-Policy (feature restriction).

These headers together provide defense-in-depth against multiple attack vectors. A single missing header can be exploited even with CSP in place.

const securityHeaders = [
  { key: 'X-Frame-Options', value: 'DENY' },
  { key: 'X-Content-Type-Options', value: 'nosniff' },
  { key: 'Referrer-Policy', value: 'strict-origin-when-cross-origin' },
  { key: 'Strict-Transport-Security', value: 'max-age=63072000; includeSubDomains; preload' },
  { key: 'Permissions-Policy', value: 'camera=(), microphone=(), geolocation=()' },
];

module.exports = {
  async headers() {
    return [{ source: '/(.*)', headers: securityHeaders }];
  },
};

REPL Summary — The 3 Commands That Verify Your Security Posture

Before every deployment, run these three commands:

1. curl -sI https://example.com | grep -iE '(content-security|strict-transport|x-frame|x-content|referrer|permissions)' — verifies all 6 security headers are present.
2. curl -s https://example.com | grep -oE '"apiKey"|"secret"|"token"' | head -5 — checks for exposed secrets in HTML source.
3. curl -v -X POST -H 'Origin: https://evil.com' https://example.com/_next/... 2>&1 | grep -i 403 — verifies Server Actions reject cross-origin requests.

curl -sI "$URL" | grep -iE '(content-security|strict-transport|x-frame|x-content|referrer|permissions)' || echo 'MISSING HEADERS!'
curl -s "$URL" | grep -oE '"apiKey"|"secret"|"token"' || echo 'None found'
ACTION_URL=$(curl -s "$URL" | grep -oP '/_next[^"]+' | head -1)
curl -v -X POST -H 'Origin: https://evil.com' "${URL}${ACTION_URL}" 2>&1 | grep -i 403 || echo 'WARNING: No 403'