Content Security Policy (CSP)

Content Security Policy (CSP) is a standardized HTTP response header defined by the W3C that grants web application architects granular control over the origins from which browsers are permitted to load and execute dynamic assets. By declaring approved sources for scripts, stylesheets, images, fonts, iframes, and network connections, a properly configured CSP serves as an indispensable defense-in-depth barrier against Cross-Site Scripting (XSS), clickjacking, and unauthorized data exfiltration.

Build, validate, and test your security policy headers visually with our CSP Header Builder tool or inspect live production server headers using our HTTP Headers Analyzer.

---

Technical Specifications at a Glance

Specification	Details
Standard Specifications	W3C CSP Level 2 (2016) & W3C CSP Level 3 (Working Draft)
HTTP Response Header	Content-Security-Policy
Testing / Staging Header	Content-Security-Policy-Report-Only
Alternative Mechanism	<meta http-equiv="Content-Security-Policy" content="...">
Scope of Enforcement	Client-side browser document execution layer

---

Essential CSP Directives Matrix

A CSP policy is composed of semicolon-delimited directives specifying resource restrictions:

Directive	Regulated Resource Type	Security Impact
default-src	Fallback default for all uncategorized fetch directives	Baseline safety net; sets fallback origins.
script-src	Valid sources for JavaScript files and workers	Highest priority: Neutralizes injected malicious scripts.
style-src	Valid origins for CSS stylesheets and inline <style>	Mitigates CSS-based keylogging and phishing overlays.
img-src	Valid origins for images and favicons	Controls image loading and tracking pixels.
connect-src	Valid endpoints for fetch(), XMLHttpRequest, and WebSockets	Prevents unauthorized credential or data exfiltration.
font-src	Valid sources for web fonts (@font-face)	Restricts external typography CDN fonts.
frame-src	Valid origins permitted to embed iframes	Mitigates embedded phishing attacks and clickjacking.
frame-ancestors	Restricts which parent origins may embed the page in <frame>	Modern, superior replacement for legacy X-Frame-Options.
upgrade-insecure-requests	Instructs browser to rewrite http:// URLs to https://	Eliminates mixed-content security warnings.

---

The Danger of unsafe-inline and unsafe-eval

Many legacy configurations use relaxed keywords that severely undermine security:

• 'unsafe-inline': Allows inline <script> tags, inline event listeners (onclick="..."), and javascript: URIs. Enabling this completely eliminates XSS protection, allowing attackers to execute injected code.
• 'unsafe-eval': Permits string-to-code execution functions like eval(), new Function(), and setTimeout("string").

Modern Alternatives: Nonces and Hashes

Instead of enabling 'unsafe-inline', modern web frameworks (like Next.js) leverage cryptographic nonces or SHA-256 hashes:

1. Cryptographic Nonce: The server generates a unique, cryptographically random Base64 string per HTTP response and matches it in the script tag:

   <!-- HTTP Header: script-src 'nonce-rAnd0m123' -->
   <script nonce="rAnd0m123">
     console.log("Authorized inline script executed safely");
   </script>
   

2. SHA-256 Hash: Whitelists the exact cryptographic digest of an inline script snippet ('sha256-b873f...').

---

Recommended Production Strict CSP Template

A modern strict CSP template utilizing nonces and strict-dynamic:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'nonce-{RANDOM_NONCE}' 'strict-dynamic';
  style-src 'self' 'unsafe-inline';
  img-src 'self' data: https:;
  font-src 'self' https://fonts.gstatic.com;
  connect-src 'self' https://api.wtool.dev;
  frame-ancestors 'none';
  base-uri 'self';
  form-action 'self';
  upgrade-insecure-requests;

---

Staging with Content-Security-Policy-Report-Only

Deploying a strict CSP on a live production website can inadvertently break legitimate third-party analytics or widgets.

To safely diagnose violations before active enforcement, send the Content-Security-Policy-Report-Only header paired with a report-to or report-uri directive:

Content-Security-Policy-Report-Only:
  default-src 'self';
  script-src 'self';
  report-uri /api/csp-violation-report;

The browser evaluates the policy and dispatches structured JSON error payloads to your monitoring endpoint whenever a rule is violated, without blocking the user's execution flow.

---

Frequently Asked Questions

Can CSP protect against all types of XSS?

CSP provides a robust, defense-in-depth safety net that prevents browser execution of injected scripts. However, it is not a replacement for proper server-side input validation and contextual HTML Entities encoding. A comprehensive security architecture combines sanitization with strict CSP headers.

What is the difference between frame-ancestors and X-Frame-Options?

X-Frame-Options is a legacy HTTP header with limited configuration options (DENY, SAMEORIGIN). frame-ancestors is the modern W3C CSP directive that allows whitelisting multiple specific parent origins and supports wildcard subdomains. Browsers that support CSP prioritize frame-ancestors over X-Frame-Options.

Can I set a Content Security Policy via <meta> tag?

Yes, using <meta http-equiv="Content-Security-Policy" content="...">. However, meta tags do not support frame-ancestors, report-uri, or sandbox directives. Setting CSP as an authentic HTTP response header from the web server or reverse proxy is always recommended.