Content Security Policy (CSP)

Cross-Site Scripting (XSS) remains one of the most common web vulnerabilities. Despite decades of awareness, it continues to appear in security audits and enables some of the most damaging web attacks. Content Security Policy (CSP) is the browser's most powerful built-in defense against XSS.

A CSP is an HTTP response header that tells the browser exactly which sources of content are allowed to load on your page. Scripts from unapproved sources are blocked automatically, even if an attacker manages to inject malicious code into your HTML. This makes CSP a critical defense-in-depth layer that protects users even when application-level security fails.

This guide explains how CSP works, which directives you need, how to implement it without breaking your site, and the common mistakes that render CSP ineffective. For detailed browser specifics, consult the MDN Web Docs on CSP.

The Power of the Whitelist

A Content Security Policy (CSP) is an HTTP response header that lets you declare exactly which sources of content the browser is allowed to load. Any content from undeclared sources is automatically blocked by the browser.

This severely limits the damage an attacker can do even if they manage to inject malicious code into your page. The browser simply refuses to execute it if the source is not on the whitelist.

• XSS prevention: CSP blocks the execution of injected scripts, neutralizing the most common web vulnerability category.
• Supply chain protection: If a third-party CDN is compromised, CSP prevents the modified script from exfiltrating data to unauthorized domains.
• Compliance: Security frameworks (SOC 2, PCI-DSS) and vendor security reviews expect CSP as a standard security measure.
• Data exfiltration prevention: The connect-src directive prevents malicious scripts from sending stolen data to attacker servers.
• GDPR technical measure: CSP is considered an “appropriate technical measure” under GDPR Article 32, helping meet the requirement for data protection by design.

Blocking Malicious Execution

Cross-Site Scripting (XSS) occurs when an attacker tricks the browser into executing malicious JavaScript. A strong CSP mitigates this by:

• Blocking inline scripts: Injected <script>malicious()</script> tags are dropped because inline scripts are not in the whitelist.
• Restricting domains: Only scripts from explicitly whitelisted origins can execute. A script loaded from evil.com is blocked automatically.
• Preventing eval(): Dynamic code execution functions like eval() and new Function() are blocked by default.
• Blocking data exfiltration: Even if a script executes, connect-src prevents it from sending data to unauthorized servers.

Understanding Directives

The absence of CSP has contributed to major breaches:

• British Airways (2018): No CSP allowed a Magecart script to capture 380,000 payment cards from the checkout page. CSP would have blocked the unauthorized script and prevented data exfiltration.
• Ticketmaster (2018): A compromised third-party chatbot widget injected a payment skimmer. CSP with SRI would have blocked the modified script from executing.
• Newegg (2018): Magecart attackers injected a 15-line payment skimmer that ran undetected for a month. A script-src CSP directive would have blocked the unauthorized domain.

1. Run a header scan: Use the Security Headers Checker to see if your CSP header is present and review its directives.
2. Check DevTools: Open Console tab, CSP violations appear as errors with the blocked resource URL and the violated directive.
3. Set up violation reporting: Add a report-uri or report-to directive to collect violation data in production.
4. Use CSP Evaluator: Google's CSP Evaluator tool analyzes your policy for common weaknesses and recommendations.

Deployment Strategy

1. Start with Report-Only: Use Content-Security-Policy-Report-Only first to log violations without blocking content. Monitor for at least one week.
2. Build your policy: Use the CSP Generator to build a policy interactively.
3. Deploy incrementally: Start with default-src 'self' and add allowed sources as needed based on violation reports.
4. Replace inline scripts with nonces: Instead of unsafe-inline, generate a random nonce for each request:

1. Start with Report-Only mode, deploy in report-only for at least a week before enforcing to avoid breaking functionality.
2. Use nonces over domain whitelists, cryptographic nonces are more secure because domain whitelists can be bypassed if a CDN is compromised.
3. Set frame-ancestors, use frame-ancestors 'none' to replace X-Frame-Options with the modern CSP-based equivalent.
4. Monitor violations in production, set up a reporting endpoint to catch policy violations. This helps you detect both misconfiguration and attempted attacks.
5. Restrict connect-src, this directive prevents data exfiltration. Only whitelist API endpoints that your application actually uses.
6. Combine with other security headers, CSP works best alongside HSTS, Referrer-Policy, and Permissions-Policy.

• Using 'unsafe-inline': This allows any inline script to execute, completely defeating CSP's XSS protection. Use nonces or hashes instead.
• Using 'unsafe-eval': Required by some older frameworks, but opens the door to code injection via eval(). Migrate to frameworks that do not require it.
• Whitelisting entire CDN domains: If you whitelist https://cdn.jsdelivr.net, an attacker can host malicious code on the same CDN. Use SRI hashes alongside domain whitelists.
• Not setting default-src: Without a default-src fallback, resource types without specific directives have no restrictions.
• Deploying without Report-Only first: Enforcing an untested CSP can break your entire site. Always test in report-only mode first.
• Forgetting about WebSockets: If your app uses WebSockets, you need to include the WebSocket URL in connect-src.

Content Security Policy is the single most effective browser-level defense against XSS and supply-chain attacks. It is not a replacement for secure coding practices, but it catches the attacks that slip through. Every website should have a CSP, the question is not whether to implement one, but how strict to make it.

Start with Report-Only mode, build your policy incrementally using the CSP Generator, and monitor violations in production. Combined with other security headers, CSP creates a robust defense-in-depth strategy.