Content Security Policy (CSP) & Security Header Builder

Content Security Policy (CSP) is a standardized HTTP response header (and declarative security mechanism) that restricts the resources (such as JavaScript, CSS, Images, Fonts, Frames, and WebSockets) that the browser is allowed to load and execute for a given page. CSP represents the primary defense-in-depth mitigation layer against Cross-Site Scripting (XSS), clickjacking, packet sniffing, malicious script injection, and unauthorized data exfiltration.

Without a strict CSP, if an attacker discovers an input sanitization flaw or a compromised third-party NPM dependency on your site, they can inject arbitrary scripts to siphon authentication tokens, session cookies, credit card credentials, or customer PII. A properly constructed CSP instructs modern browser engines to refuse executing unapproved inline scripts or fetching resources from untrusted external origins.

Modern CSP Level 3 comprises granular directives governing specific asset types:

• default-src: The global fallback rule for all fetch directives if an explicit directive is not provided. Always establish a restrictive default-src 'self' base.
• script-src & script-src-elem: Controls valid execution sources for JavaScript. Avoid 'unsafe-inline' and 'unsafe-eval' whenever possible in production; use cryptographic nonces or SHA-256 hashes instead.
• style-src & style-src-elem: Restricts stylesheets and inline CSS blocks. While CSS-in-JS and Tailwind frequently require 'unsafe-inline', scoping external CDNs (e.g. Google Fonts) prevents stylesheet-based data exfiltration.
• img-src: Regulates image and icon sources. Common tokens include 'self' data: blob: https: to support modern SVG placeholders, avatar services, and cloud storage buckets.
• connect-src: Restricts targets for fetch(), XMLHttpRequest, WebSocket connections (ws:, wss:), and EventSource streams. Critical for preventing stolen data exfiltration to attacker command-and-control servers.
• font-src: Governs web typography (e.g. Google Fonts fonts.gstatic.com, Typekit).
• object-src: Restricts legacy browser plugins (Flash, Java applets, ActiveX). Best practice: Always enforce object-src 'none' on modern web applications.
• frame-ancestors: The modern, superior replacement for X-Frame-Options. Dictates which domains can embed your webpage inside <iframe>, <frame>, or <object> tags, preventing UI redressing and clickjacking.
• base-uri: Restricts URLs that can appear in a document's <base> element, preventing base-tag injection attacks that rewrite relative URLs.
• form-action: Restricts valid target endpoints for HTML <form> submissions.

A comprehensive web security posture pairs CSP with modern HTTP response headers:

• Strict-Transport-Security (HSTS): Forces browsers to interact with your domain exclusively over encrypted HTTPS connections, mitigating man-in-the-middle (MITM) attacks and SSL stripping. Production best practice: max-age=63072000; includeSubDomains; preload (eligible for the global Chrome/Firefox HSTS preload list).
• X-Content-Type-Options (nosniff): Prevents browser MIME-type sniffing, forcing the browser to adhere strictly to the declared Content-Type header. Stops executable scripts disguised as innocent image or text files.
• X-Frame-Options: Legacy clickjacking prevention (DENY or SAMEORIGIN). Maintained alongside CSP frame-ancestors for backwards compatibility with legacy browsers.
• Referrer-Policy: Controls how much referrer metadata (origin vs full URL) is leaked to external sites when users click outbound links. Modern standard: strict-origin-when-cross-origin.
• Permissions-Policy (formerly Feature-Policy): Granularly disables sensitive browser hardware APIs (e.g. camera=(), microphone=(), geolocation=(), interest-cohort=()), protecting user privacy and blocking unwanted tracking scripts.

Next.js App Router applications support two primary CSP implementation strategies:

1. Static Headers in next.config.mjs: Ideal for static sites, SSG, and marketing pages. Headers are defined inside the headers() async function in next.config.mjs. For inline styles or scripts, SHA-256 hashes or 'unsafe-inline' can be declared.
2. Dynamic Nonce Middleware in middleware.ts: Recommended for dynamic, authenticated SSR applications. Next.js generates a unique cryptographically secure random nonce per request (crypto.randomUUID()), injects it into script-src 'nonce-${nonce}' 'strict-dynamic', and forwards the nonce to root layout components via requestHeaders.set('x-nonce', nonce).