Content Security Policy (CSP)

Security Glossary - Security Headers

Definition: Content Security Policy is a security header that controls which resources (scripts, styles, images, fonts, frames) a browser is allowed to load on a page. By specifying allowed sources for each resource type, CSP helps prevent cross-site scripting (XSS), clickjacking, and other code injection attacks.

Quick Reference

Directive	Purpose	Example
default-src	Fallback for all resource types	'self'
script-src	JavaScript sources	'self' 'nonce-abc123'
style-src	CSS sources	'self' 'unsafe-inline'
img-src	Image sources	'self' data: https:
connect-src	AJAX, WebSocket, fetch targets	'self' https://api.example.com
frame-ancestors	Who can embed this page	'self' (replaces X-Frame-Options)

Why CSP Matters

CSP is one of the most powerful defenses against XSS attacks. Even if an attacker finds an XSS vulnerability in your application, a strict CSP can prevent their injected script from executing. By default, a CSP with script-src that does not include 'unsafe-inline' will block inline scripts, which is how most XSS payloads are delivered.

Implementing CSP effectively requires understanding your application's resource loading patterns. Start with Content-Security-Policy-Report-Only to monitor what would be blocked without actually breaking anything. Once you have identified all legitimate resource sources, switch to enforcing mode.

A common mistake is setting an overly permissive CSP (like script-src *) that provides no real protection. An effective CSP uses specific domains or nonce-based policies. The strictest and most recommended approach is nonce-based CSP with strict-dynamic, which only allows scripts that carry a server-generated nonce.

How to Verify

A security audit checks for the Content-Security-Policy header and evaluates its strictness. The audit identifies overly permissive directives and missing protections. Use report-uri or report-to to collect violation reports during rollout.

Common Misconceptions

Myth: CSP replaces the need for input sanitization

Reality: CSP is a defense-in-depth measure, not a replacement for secure coding. If your application has XSS vulnerabilities, CSP mitigates the impact but does not fix the root cause. Attackers may find CSP bypasses.

Myth: Adding 'unsafe-inline' to script-src is acceptable

Reality: Using 'unsafe-inline' defeats the primary purpose of CSP against XSS. If you need inline scripts, use nonces or hashes instead. 'unsafe-inline' is ignored when a nonce or hash is present in the directive.

Run a Security Audit

Frequently Asked Questions

Will CSP break my website?

It can if misconfigured. Start with Content-Security-Policy-Report-Only to see what would be blocked without affecting users. Review the reports, adjust your policy, and only switch to enforcing mode once you have eliminated false positives.

What is the minimum useful CSP?

At minimum, set default-src 'self' to restrict resources to your own domain, and frame-ancestors 'self' to prevent clickjacking. For better XSS protection, add script-src with nonces or strict-dynamic instead of 'unsafe-inline'.