Content Security Policy (CSP) Generator & Validator
Build strict, compliant HTTP Content Security Policy headers in seconds. Mitigate Cross-Site Scripting (XSS), prevent UI Clickjacking, audit insecure directive configurations, and export ready-to-deploy snippets for Nginx, Apache, Caddy, and Next.js.
Directive Configurations
Click to toggle common sourcesClickjacking defense (Who can iframe this site)
Plugins & Flash applets
Plugin execution strictly disabled.
Base tag injection vector mitigated.
Restricts iframe parent embedding.
Forces all insecure legacy resources to TLS.
Reserved banner container configured with strict Core Web Vitals CLS = 0 layout preservation.
How Content Security Policy Protects Web Applications
Content Security Policy (CSP) is an HTTP response header defined by the W3C that gives web developers granular control over the resources (scripts, images, stylesheets, fonts, frames, and network sockets) a browser is authorized to fetch and execute for a given origin.
Even if an attacker discovers an unsanitized injection vulnerability (such as a reflected input parameter or stored user comment), a robust CSP prevents the browser from executing the malicious JavaScript payload or sending stolen session cookies to an external command-and-control server.
Directives like script-src 'self' restrict code execution solely to scripts hosted on the same origin, neutralizing arbitrary remote script tags inserted by attackers.
By configuring connect-src 'self', attempts by injected malware to exfiltrate private credentials or keystrokes via fetch(), XHR, or WebSockets are blocked at the browser network layer.
The frame-ancestors 'none' directive obsoletes legacyX-Frame-Options: DENY headers by preventing invisible framing in malicious third-party sites.
The Danger of 'unsafe-inline' and 'unsafe-eval'
Many development teams encounter broken styles or inline analytics scripts and hastily add 'unsafe-inline' to their policy. Doing so strips away up to 90% of CSP's defensive capability:
Classic Cross-Site Scripting occurs when untrusted user input is rendered directly into HTML as an inline tag (e.g. <script>alert(document.cookie)</script>) or an event handler (e.g. <img onerror="...">). If your policy allows inline code, the browser cannot distinguish legitimate scripts from injected attacks.
Instead of allowing all inline scripts, generate a cryptographically random cryptographic nonce per HTTP request (e.g., 'nonce-2726c7f26c'). Attach this nonce to legitimate script tags (<script nonce="2726c7f26c">). Combined with CSP Level 3's 'strict-dynamic', trusted root scripts can automatically load secondary dependencies without maintaining fragile host whitelists.
Comparative Security Matrix: Safe vs. Vulnerable Directives
| Directive | Vulnerable Configuration | Recommended Hardened Value | Threat Mitigated |
|---|---|---|---|
| script-src | 'unsafe-inline' https: * | 'self' 'nonce-{RANDOM}' 'strict-dynamic' | Stored, Reflected & DOM-based XSS |
| object-src | 'self' or unconfigured | 'none' | Flash & Java plugin code execution |
| base-uri | Unconfigured (wildcard) | 'self' or 'none' | <base href> relative script hijacking |
| frame-ancestors | Unconfigured | 'none' (or trusted origins) | UI Redressing & Clickjacking attacks |
| form-action | * or unconfigured | 'self' | Phishing form-action redirects |
Server Deployment: How to Add CSP Headers in Production
Deploying Content Security Policy at the web server layer ensures every HTML response delivers consistent headers regardless of whether pages are rendered statically or dynamically:
Place inside your server {} block in /etc/nginx/conf.d/default.conf:
Requires mod_headers enabled:
Header set Content-Security-Policy "default-src 'self'; object-src 'none';"
</IfModule>
Frequently Asked Questions
Before enforcing a strict policy that might break existing frontends, deliver it via the Content-Security-Policy-Report-Only header. The browser will log and report violations to your report-uri endpoint without blocking any user requests.
Yes, using <meta http-equiv="Content-Security-Policy" content="...">. However, certain directives like frame-ancestors, report-uri, and sandbox directives are ignored in meta tags and must be sent via real HTTP headers.
No. CSP is a defense-in-depth mitigation. You must always sanitize and contextually encode user input on the server. If an attacker bypasses CSP (e.g. through gadget scripts in trusted libraries), backend sanitization remains essential.
Google Fonts delivers its CSS stylesheet from fonts.googleapis.com (which belongs in style-src) but serves the underlying binary WOFF2 font files from fonts.gstatic.com (which belongs in font-src).