# Content Security Policy (CSP) Deep Dive
Content Security Policy (CSP) is a security standard delivered via HTTP headers or HTML meta tags that controls which resources a web browser is allowed to load and execute for a given web page. CSP serves as the primary browser-side defense against Cross-Site Scripting (XSS) attacks, clickjacking, code injection, and data exfiltration by establishing a detailed allowlist of trusted content sources.
The policy works by instructing the browser to reject any resources that do not match the specified criteria. When a web page attempts to load JavaScript from an unauthorized domain, execute inline scripts without proper authorization, or connect to prohibited endpoints, CSP blocks the request and optionally reports the violation to a designated endpoint.
CSP exists because traditional web security relied heavily on server-side input validation and output encoding, which proved insufficient against the complexity of modern web applications. As web applications became more dynamic, incorporating third-party scripts, user-generated content, and complex JavaScript frameworks, the attack surface expanded beyond what server-side controls could effectively protect. CSP shifts part of the security enforcement to the browser itself, creating a second line of defense that operates even when server-side protections fail.
The standard has evolved through three major versions. CSP Level 1 introduced basic source allowlists. CSP Level 2 added nonces, hashes, and violation reporting improvements. CSP Level 3 introduced strict-dynamic, which fundamentally changed how CSP can be implemented at scale by allowing trusted scripts to load other scripts dynamically without requiring those subsequent sources to be explicitly allowlisted.
CSP fits into the broader web security ecosystem as a critical component of defense in depth. While it cannot prevent all attacks, it significantly reduces the impact of successful code injection by limiting what malicious scripts can do once they execute. This makes CSP particularly valuable for protecting against stored XSS attacks, where malicious content persists in the application's database and affects multiple users.
CSP operates through directives delivered via the Content-Security-Policy HTTP header. Each directive controls a specific type of resource or behavior. The browser evaluates every resource request against the applicable directive and blocks requests that do not match the specified sources.
The most fundamental directive is default-src, which serves as a fallback for any resource type that does not have a specific directive defined. If a page loads images but no img-src directive exists, the browser applies the default-src policy to image requests. This creates a secure foundation where all resource types are restricted unless explicitly configured.
Script control happens through script-src, the most security-critical directive. A basic implementation might specify script-src 'self' https://cdn.example.com, allowing JavaScript only from the same origin and a specific CDN. The browser blocks any attempt to load scripts from other domains, execute inline JavaScript, or use JavaScript's eval() function.
For organizations with complex applications that require inline scripts, CSP provides two advanced mechanisms. Nonces are cryptographically random values generated server-side for each page load. The server includes the nonce in both the CSP header (script-src 'nonce-abc123') and in the script tag (