Content Security Policy (CSP) is a W3C security standard, first introduced in 2012 (CSP Level 1) and refined through CSP Level 2 (2016) and CSP Level 3 (current), that provides a declarative mechanism for web applications to specify which content sources the browser should trust. CSP is primarily designed to mitigate Cross-Site Scripting (XSS), the most prevalent class of web security vulnerability, by establishing a whitelist of approved content sources that the browser enforces, blocking any resources or scripts that originate from unapproved sources.

CSP directives form the building blocks of a policy, each controlling a specific type of resource. The default-src directive sets the fallback policy for all resource types not explicitly specified. The script-src directive controls which scripts can execute, and is the most critical for XSS prevention. The style-src directive governs CSS sources, img-src controls image loading, connect-src restricts AJAX and WebSocket connections, font-src manages font loading, and frame-src (or child-src) controls embedded iframes. The frame-ancestors directive, which replaces the X-Frame-Options header, specifies which sites can embed the current page in a frame, preventing clickjacking attacks. Each directive accepts source expressions including 'self' (same origin), 'none' (block all), specific domains, scheme-based sources (https:, data:), and hash or nonce values.

Nonce-based CSP policies represent the most secure approach for allowing inline scripts while maintaining strong XSS protection. A nonce (number used once) is a randomly generated value that the server includes in both the CSP header (script-src 'nonce-abc123') and the script tag (script nonce="abc123"). Because the nonce changes with every page load and must match exactly, an attacker who injects a script tag cannot predict the required nonce value, and the browser blocks execution. This approach is superior to 'unsafe-inline' (which defeats CSP's XSS protection entirely) and hash-based policies (which become unwieldy with many inline scripts). Google's strict CSP recommendation uses nonces combined with 'strict-dynamic', which automatically trusts scripts loaded by nonced scripts without needing to whitelist their origins.

Deploying CSP effectively requires a careful rollout strategy. The Content-Security-Policy-Report-Only header allows a policy to be tested without enforcement: violations are reported (to a URL specified by the report-to directive) but resources are not blocked. This enables teams to discover what a policy would break before it actually breaks it. Common deployment challenges include third-party scripts that load additional resources from unknown origins, inline event handlers (onclick, onload) that violate script-src policies, and dynamically generated CSS that conflicts with style-src restrictions. The report-uri and report-to directives send violation reports as JSON to a specified endpoint, providing visibility into what the policy blocks in production.