What Is CSP - How Content Security Policy Works and How to Configure It

What Is CSP (Content Security Policy)

CSP (Content Security Policy) is an HTTP response header that allows the server to control the sources from which a web page can load resources (scripts, stylesheets, images, fonts, etc.). Because the browser blocks loading or execution of resources not permitted by CSP, it can significantly mitigate XSS (Cross-Site Scripting) attacks.

While the fundamental countermeasure for XSS is output escaping, implementation oversights can never be completely eliminated. CSP serves as a defense-in-depth layer that "prevents the attacker's script from executing even if an XSS vulnerability exists." It is one of the most powerful and complex security headers.

Key Directives

CSP consists of multiple directives that specify allowed sources for each resource type.

default-src: Default policy for resources not explicitly specified by other directives. default-src 'self' allows only resources from the same origin
script-src: Controls JavaScript loading sources. The core directive for XSS prevention. Avoid 'unsafe-inline' and use nonce or hash instead
style-src: Controls CSS loading sources
img-src: Controls image loading sources
connect-src: Controls destinations for fetch, XMLHttpRequest, and WebSocket connections
font-src: Controls web font loading sources
frame-src: Controls iframe embedding sources. Also related to clickjacking prevention
frame-ancestors: Controls which parent page origins can embed your site in an iframe. Successor to X-Frame-Options

Source Value Specification

'self': Same origin
'none': Block all
'nonce-{random}': Allow only inline scripts/styles with a specific nonce value
'strict-dynamic': Also allow scripts dynamically loaded by nonce-permitted scripts
Specific domains: https://cdn.example.com

Step-by-Step Deployment

CSP deployment should proceed gradually to avoid breaking existing sites.

Step 1: Monitor with Report-Only Mode

Using the Content-Security-Policy-Report-Only header detects and reports policy violations without blocking resources. Start with this mode to understand what resources your site currently loads.

Step 2: Develop the Base Policy

Based on report analysis, add necessary resource sources to the whitelist. Start with a lenient policy and gradually tighten it.

Step 3: Production Deployment and Continuous Monitoring

Switch to the Content-Security-Policy header for production deployment. Continuously collect violation reports using the report-uri or report-to directive to address false positives and new resource requirements.

Recommended Strict Policy Example

default-src 'none'; script-src 'self' 'nonce-{random}' 'strict-dynamic'; style-src 'self' 'nonce-{random}'; img-src 'self' data:; font-src 'self'; connect-src 'self'; frame-ancestors 'none'; base-uri 'self'; form-action 'self'

This policy controls inline scripts with nonces and uses 'strict-dynamic' to also allow dynamically loaded scripts.

CSP Integration with Other Security Headers

While CSP is powerful on its own, combining it with other security headers builds more robust defenses.

Combined with HSTS: Enforces HTTPS and prevents CSP header tampering through man-in-the-middle attacks. HTTPS is a prerequisite for maximizing CSP effectiveness
X-Content-Type-Options: nosniff: Prevents MIME type sniffing and blocks execution of resources that should not be interpreted as scripts
Relationship with CORS: CSP controls resource loading sources, while CORS controls access rights for cross-origin requests. The two are complementary

CSP deployment has an initial cost, but it dramatically improves defenses against XSS and clickjacking. Incorporating CSP into the design from the start of new projects significantly reduces costs compared to later adoption.

To learn more about this topic, see HTTP Security Headers: 5 Essential Headers to Protect Your Website.

Common Misconceptions

Setting up CSP eliminates the need for XSS countermeasures: CSP is one layer of defense in depth that mitigates XSS damage, not a replacement for the fundamental XSS countermeasure (output escaping). CSP bypass techniques are also being researched, so implementing both output escaping and CSP is recommended.
CSP is too difficult to configure and unnecessary for small sites: Even small sites face XSS risks. Starting with a minimal policy (e.g., default-src 'self'; script-src 'self') makes deployment easy. You can gradually tighten it while checking impact with Report-Only mode.

CSP (Content Security Policy)