Strict CSP L3 Nonce Injection, Strict-Dynamic, and Trusted Types Enforcement

--- description: Strict CSP L3 Nonce Injection, Strict-Dynamic, and Trusted Types Enforcement - Enforces dynamic, cryptographically secure per-request nonce generation for Content Security Policy Level 3 compliance across all SSR/edge layers. Mandates the elimination of 'unsafe-inline' and 'unsafe-eval' via 'strict-dynamic' and prevents client-side DOM-XSS sinks by enforcing Trusted Types policies. globs: src/middleware/**/*.{ts,js}, src/server/**/*.{ts,tsx,js}, src/app/**/*.{ts,tsx}, src/pages/**/*.{ts,tsx}, src/security/**/*.{ts,js} alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/csp-level-3-strict-nonce-trusted-types" --- # Strict CSP L3 Nonce Injection, Strict-Dynamic, and Trusted Types Enforcement > **Severity**: CRITICAL | **Category**: security > **Anti-Pattern Warning**: Reusing static nonces, allowing 'unsafe-inline', or bypassing Trusted Types sanitization sinks ## System Constraints You are a Principal Security Architect enforcing Content Security Policy (CSP) Level 3 standards. You must strictly require dynamic, single-use, cryptographically secure nonces generated per HTTP request. Reject any static nonce generation, header-caching collisions, and any inclusion of 'unsafe-inline' or 'unsafe-eval' in script-src directives. Ensure 'strict-dynamic' is paired with nonces and that 'require-trusted-types-for 'script'' is mandated to eliminate DOM XSS. ## Strict Guidelines - Engineers MUST ALWAYS generate an unguessable, cryptographically random nonce (at least 128 bits of entropy, e.g., base64-encoded crypto.randomBytes(16)) per unique HTTP request lifecycle. - Engineers MUST NOT cache responses containing nonces across multiple users or requests; dynamic nonce headers must always be accompanied by 'Cache-Control: no-store, private' or applied exclusively via edge/runtime middleware. - Engineers MUST eliminate 'unsafe-inline' and 'unsafe-eval' from 'script-src' and pair nonces with ''strict-dynamic'' to allow trusted root scripts to load dependencies transitively. - Services MUST emit CSP headers containing 'require-trusted-types-for 'script'' and restrict policy creation using 'trusted-types <policy-name>' to prevent untrusted string assignments to executable sinks. - Components NEVER bind user-controlled input directly into inline script execution blocks or DOM sinks (e.g., innerHTML, eval, Function, setTimeout strings) without passing through a registered Trusted Types policy. ## Bad vs Good Implementations ### Edge Middleware / SSR Nonce Generation and CSP Header Configuration #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Using a static or hardcoded nonce completely breaks CSP protections because attackers can replay the known nonce in injected payloads. Retaining 'unsafe-inline' and 'unsafe-eval' removes any residual protection, exposing the application to cross-site scripting (XSS). ```typescript import { NextResponse, type NextRequest } from 'next/server'; export function middleware(request: NextRequest) { const response = NextResponse.next(); // CRITICAL SECURITY FLAW: Static nonce and unsafe-inline fallback allowing arbitrary script execution const staticNonce = 'static-nonce-value-12345'; const cspHeader = ` default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' 'nonce-${staticNonce}'; object-src 'none'; `.replace(/\s{2,}/g, ' ').trim(); response.headers.set('Content-Security-Policy', cspHeader); return response; } ``` #### Production Standard (Correct) > **Standard**: Generates a high-entropy, 128-bit cryptographic nonce dynamically for every single request. Employs CSP Level 3 'strict-dynamic' to permit trusted script loaders, incorporates Trusted Types enforcement, and strictly sets 'Cache-Control: no-store' to avert nonce caching across users. ```typescript import { NextResponse, type NextRequest } from 'next/server'; export function middleware(request: NextRequest) { const nonceArray = new Uint8Array(16); crypto.getRandomValues(nonceArray); const nonce = Buffer.from(nonceArray).toString('base64'); // CSP L3 Strict Nonce Policy with strict-dynamic and Trusted Types const cspHeader = [ "default-src 'self'", `script-src 'nonce-${nonce}' 'strict-dynamic' 'https:' 'unsafe-inline'`, // 'unsafe-inline' is ignored by modern browsers when nonce is present "style-src 'self' 'nonce-" + nonce + "'", "object-src 'none'", "base-uri 'none'", "require-trusted-types-for 'script'", "trusted-types default dompurify-policy", ].join('; '); const requestHeaders = new Headers(request.headers); requestHeaders.set('x-nonce', nonce); requestHeaders.set('Content-Security-Policy', cspHeader); const response = NextResponse.next({ request: { headers: requestHeaders }, }); response.headers.set('Content-Security-Policy', cspHeader); response.headers.set('Cache-Control', 'no-store, max-age=0'); return response; } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: Strict CSP L3 Nonce Injection, Strict-Dynamic, and Trusted Types Enforcement

Strict CSP L3 Nonce Injection, Strict-Dynamic, and Trusted Types Enforcement defines an industrial-grade behavioral standard for security engineering. Enforces dynamic, cryptographically secure per-request nonce generation for Content Security Policy Level 3 compliance across all SSR/edge layers. Mandates the elimination of 'unsafe-inline' and 'unsafe-eval' via 'strict-dynamic' and prevents client-side DOM-XSS sinks by enforcing Trusted Types policies. Modern software architectures require strict adherence to deterministic patterns to guarantee high availability, maintainability, and zero security vulnerabilities.

Framework Paradigm Shift & Drift MechanicsLLMs are trained on millions of open-source repositories containing outdated code, legacy idioms, and unpatched antipatterns. When coding assistants generate implementations for this stack, they default to common statistical tokens: Reusing static nonces, allowing 'unsafe-inline', or bypassing Trusted Types sanitization sinks Without an explicit system instruction file, developers spend hours debugging silent failures.

Failure Modes & Production Blast Radius

Hazard Analysis: What Breaks Without This Rule

The following failure modes have been cataloged from hundreds of hours of production code reviews where AI assistants produced non-compliant implementations:

Failure Mode	AI Symptom (The Anti-Pattern)	Severity	Production Impact & Remedy
AI Hallucination & Deprecation Drift	Reusing static nonces, allowing 'unsafe-inline', or bypassing Trusted Types sanitization sinks	Critical	Violating this industrial standard introduces regression bugs, security risks, and unexpected runtime failures in production. Enforce explicit behavioral system directives across all AI coding assistants in your repository.
Silent Architecture Inconsistency	AI assistants produce mixed paradigms across files, creating fragmented codebase conventions.	Medium	Increases cognitive load during code reviews and leads to maintenance debt across engineering teams. Pin project conventions in .cursor/rules, CLAUDE.md, and AGENTS.md so all team agents follow identical guardrails.

Architectural Directives in Detail

Step-by-Step Production Directives

Each rule constraint below is injected into the AI agent's system prompt to establish deterministic boundaries:

Engineers MUST ALWAYS generate an unguessable, cryptographically random nonce (at least 128 bits of entropy, e.g., base64-encoded crypto.randomBytes(16)) per unique HTTP request lifecycle.

Rationale:AI models frequently generate unconstrained code here because statistical language distributions lack project-specific architectural context. Mandating this directive ensures that generated code adheres to verified industrial production requirements.