Enterprise Strict Content Security Policy (CSP): The Production Guide for Next.js & Modern Web Apps

For over a decade, engineering teams attempted to secure their web applications using domain-allowlist Content Security Policies. A typical header looked like this:

In theory, this restricted script execution to first-party code and three approved external content delivery networks. In practice, security researchers demonstrated that over 95% of domain-based CSP allowlists are completely bypassable.

The Anatomy of an Allowlist Bypass

Shared CDNs host hundreds of thousands of JavaScript libraries and legacy utilities. If an attacker identifies an open redirect, a JSONP endpoint with an arbitrary callback parameter, or an older version of AngularJS on any domain present in your allowlist, they can construct an executable XSS payload:

The browser permits the script tag because https://cdnjs.cloudflare.com matches the allowlist. The payload executes with full access to the user session, bypassing the entire defense.

Allowlist CSP vs. Strict CSP Comparison

Modern browser security engineering (spearheaded by the Google Information Security Team and W3C CSP Level 3) abandoned allowlists in favor of Strict CSP.

A Strict CSP abandons domain matching completely. Instead of telling the browser *where* code can be downloaded from, it instructs the browser to execute *only code that holds a cryptographically random, unguessable token (a nonce)*.

The Canonical Strict CSP Header

Let's dissect each directive in this policy:

1. `base-uri 'none'`: Prevents attackers from injecting <base href="https://evil.com/">, which would redirect all relative URL script requests and form submissions to an attacker-controlled origin.
2. `object-src 'none'`: Disables legacy plugins like Flash, Java applets, and ActiveX. These run outside browser security models and are completely unneeded in modern applications.
3. `'nonce-{RANDOM_VALUE}'`: A cryptographically random base64 string generated fresh on every single HTTP request. Only inline and external scripts possessing an exact matching nonce="..." attribute will execute.
4. `'strict-dynamic'`: The linchpin of modern CSP. It instructs the browser that any script explicitly trusted by the nonce is granted the authority to dynamically load subordinate scripts via document.createElement('script').
5. `https: 'unsafe-inline'` (Backward-Compatibility Fallbacks):

• When a modern browser supporting CSP Level 3 encounters 'strict-dynamic', the specification requires it to ignore https:, 'self', and all domain expressions in script-src.
• When a browser encounters a valid nonce, it automatically ignores 'unsafe-inline'.
• If an ancient browser (CSP Level 1 or 2) visits the site, it disregards 'strict-dynamic' and falls back to https:. Your security degrades gracefully without breaking the user experience.

Implementing a nonce-based Strict CSP in Next.js requires coordination between Edge Middleware, HTTP request headers, and Server Components.

Because Next.js App Router relies on Streaming Server-Side Rendering (SSR) and React Server Components (RSC), we cannot evaluate headers after page rendering begins. The nonce must be generated in `middleware.ts`, attached to the outgoing response, and forwarded downstream into request headers so the Root Layout can access it.

Step 1: Configure Edge Middleware (`middleware.ts`)

Create or update middleware.ts in your project root:

Step 2: Ingest the Nonce in Root Layout (`app/layout.tsx`)

In Next.js App Router, the Root Layout is a React Server Component. You read the x-nonce header injected by middleware using headers() from next/headers:

Next.js automatically detects the Content-Security-Policy header in the response and propagates the nonce to all framework-managed <script> hydration bundles.

The primary obstacle enterprise engineering organizations face when adopting CSP is third-party analytics and marketing tooling (Google Tag Manager, Segment, Mixpanel, Datadog RUM).

In traditional allowlist architectures, adding one marketing widget required adding dozens of unknown CDN endpoints to script-src, connect-src, and img-src.

How 'strict-dynamic' Resolves the GTM Paradox

Thanks to `'strict-dynamic'`, you do not need to allowlist every domain that Google Tag Manager downloads. As long as the root GTM snippet is executed with a valid cryptographic nonce, any script injected into the DOM by GTM inherits that trust automatically.

Critical Enterprise GTM Configuration

While 'strict-dynamic' permits dynamically generated external scripts, it blocks inline JavaScript execution inside custom HTML tags within GTM.

To maintain strict security without breaking marketing workflows:

1. In the GTM Container Settings, check Support document.write.
2. Avoid GTM "Custom HTML" tags containing raw <script> blocks. Instead, use official Community Template tags or distribute custom scripts as hosted external JS bundles.
3. If custom inline JavaScript tags in GTM are mandatory, pass the nonce through GTM's dataLayer and configure the tag template to append the nonce attribute when creating DOM nodes.

While script-src is the primary vector for arbitrary code execution, CSS injection attacks (style-based data exfiltration via attribute selectors) represent a genuine threat.

However, modern UI frameworks (Tailwind CSS, Emotion, Styled Components, and Radix UI) inject dynamic styles or require inline style attributes for positioning, animations, and transitions.

Directive Breakdown for Styles

W3C CSP Level 3 differentiates between inline style tags (<style>) and inline style attributes (style="color: red"):

Why Nonces on Styles Are Harder Than Scripts

Unlike scripts, browsers do not support 'strict-dynamic' for styles. If you enforce nonces on style-src, every stylesheet loaded by a third-party widget will be rejected unless that widget specifically knows how to pass the nonce.

For the vast majority of enterprise production applications, hardened script security via Strict CSP with `script-src` nonces combined with standard `style-src 'self' 'unsafe-inline'` achieves the optimal security-to-maintainability posture.

A Content Security Policy without violation reporting is operating blind. You cannot discover third-party vendor script changes, browser extension interference, or active attack attempts without telemetry.

The legacy report-uri directive is officially deprecated in CSP Level 3 in favor of the W3C Reporting API (`report-to`).

Modern Reporting Headers

> Note: Include both report-to and report-uri. Contemporary Chromium and Firefox browsers utilize Reporting-Endpoints, while older WebKit/Safari builds fall back to report-uri.

Structure of a Violation Payload

When a violation occurs, the browser transmits a JSON payload to your reporting endpoint:

Filtering Noise in Enterprise Observability

In production, up to 90% of raw CSP violation reports originate from browser extensions (ad blockers, password managers, translation tools) or local malware rather than legitimate application bugs.

Implement automated filtering at your ingestion gateway:

1. Ignore `chrome-extension://`, `moz-extension://`, and `safari-web-extension://` blocked URIs.
2. Filter out common ad-blocker script injections (e.g., about:blank, injectedScript).
3. Group by `effective-directive` and `blocked-uri` to alert on sudden volume spikes indicative of an actual stored XSS campaign.

Never deploy a strict Content Security Policy directly into blocking mode in an enterprise production environment. Doing so risks catastrophic outages for edge-case user workflows and uncoordinated marketing scripts.

Follow this four-phase deployment lifecycle:

Phase 1: Audit and Baseline

Use our free Content Security Policy Generator & Linter to draft your initial directives, and run the Security Header Analyzer against your staging domain to verify existing HTTP headers.

Phase 2: Report-Only Mode

Deploy the policy using the Content-Security-Policy-Report-Only response header. In this mode, the browser logs and dispatches violation reports to your endpoint without blocking any resource execution. The user experience remains 100% unaffected.

Phase 3: Telemetry Analysis (14 Days)

Monitor reporting telemetry for at least two business cycles. Check for:

• Embedded payment iframes or 3D Secure verification modals that require frame-src.
• Customer support widgets (Zendesk, Intercom) dynamically loading auxiliary bundles.
• Third-party polyfills required by legacy enterprise browser environments.

Phase 4: Full Enforcement and SOC 2 / PCI-DSS Compliance

Switch the response header to Content-Security-Policy. With cryptographic nonces and 'strict-dynamic' operating across all routes, your application achieves hardened defense-in-depth, fulfilling the stringent application security controls demanded by SOC 2 Type II, ISO 27001 Annex A.14, and PCI-DSS 4.0 Requirement 6.4.3.