Content Security Policy (CSP) Deep Dive
Deep dive into Content Security Policy covering directives, nonce-based policies, strict-dynamic, common bypass techniques, and deployment strategies for XSS prevention.
Continue your mission
Deep dive into Content Security Policy covering directives, nonce-based policies, strict-dynamic, common bypass techniques, and deployment strategies for XSS prevention.
# 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 ( CDA Theater missions that address topics covered in this article. CMMC 2.0 requires defense contractors to demonstrate cybersecurity maturity at three levels. HITRUST CSF harmonizes multiple frameworks into one certifiable standard for healthcare. Automate compliance scanning using OpenSCAP, InSpec, and custom policy checks. Written by CDA Editorial Found an issue? Help improve this article.script-src 'nonce-abc123') and in the script tag (Related CDA Missions
Related Articles
FrameworksRGAIntermediateCMMC 2.0 Cybersecurity Maturity Model
1,656 words9 min readFrameworksRGAIntermediateHITRUST CSF for Healthcare
1,859 words10 min readFrameworksRGAIntermediateCompliance Scanning Automation Lab
1,933 words10 min readWas this helpful?The Academy
Explore The Academy