Implement Robust Content Security Policies

This skill provides expertise in Content Security Policy (CSP), specializing in designing, implementing, and maintaining robust CSP configurations that protect web applications from XSS, data injection, and other client-side attacks while preserving functionality. Core CSP principles cover deny-by-default fetch directives (default-src as a fallback, specific directives like script-src/style-src overriding it, child-src deprecated in favor of frame-src/worker-src) and the evaluation order (check the specific directive, fall back to default-src, apply source expressions and keywords, evaluate unsafe-* keywords and nonce/hash exceptions).

A progressive CSP rollout strategy moves through three phases: Phase 1 uses Content-Security-Policy-Report-Only to observe violations without blocking anything; Phase 2 applies a restrictive baseline policy (default-src 'self' with unsafe-inline still allowed for scripts/styles as a transitional step) with reporting; Phase 3 removes unsafe keywords entirely in favor of nonces, adding base-uri/form-action/frame-ancestors restrictions. Nonce implementation best practices cover server-side nonce generation (cryptographically random per-request nonces set as a response header) and their use in HTML templates (inline scripts/styles tagged with the matching nonce attribute). Hash-based CSP for static content covers generating a SHA256 hash of specific inline content and allowlisting that exact hash in the policy.

Advanced CSP configurations cover strict-dynamic for modern applications (trusting scripts loaded by already-trusted scripts, reducing allowlist maintenance) and per-environment configuration (looser development policies allowing unsafe-eval/inline and websockets, versus a strict nonce-based production policy). CSP bypass prevention explicitly documents dangerous patterns to avoid (wildcard script-src, data: URIs combined with unsafe-inline, overly broad https: with unsafe-inline) alongside safe alternatives (nonce/hash instead of unsafe-inline, refactoring away from eval() instead of unsafe-eval, and specific trusted domains instead of broad ones). Reporting and monitoring covers configuring a report-uri endpoint and a server-side handler that logs violation details (violated directive, blocked URI, source file, line number). Framework-specific implementation covers Express.js with the Helmet middleware (a directive-based configuration object) and Django settings (CSP_DEFAULT_SRC and related settings).

Use this skill when implementing or hardening Content Security Policy for a web application - rolling it out progressively, moving off unsafe-inline/unsafe-eval, or setting up violation monitoring. It is well suited to applications with inline scripts/styles that need a migration path to a strict policy. It is not meant for APIs with no browser-rendered content, or for a policy already fully hardened with no further tightening needed.

Input: the application's current script/style/resource loading patterns and framework.

Output: a phased CSP rollout (report-only, baseline, strict), nonce or hash-based script allowlisting, and violation reporting setup. Example strict nonce-based policy:

Content-Security-Policy: default-src 'self';
  script-src 'self' 'nonce-{random}';
  style-src 'self' 'nonce-{random}';
  base-uri 'self';
  form-action 'self';
  frame-ancestors 'none'

Works with Express.js (via Helmet), Django, and other server-side frameworks to set CSP headers, and with browser CSP violation reporting endpoints.

Web application security engineers implementing or hardening CSP, and teams migrating from unsafe-inline/unsafe-eval to a strict, nonce-based policy.