Content Security Policy (CSP) Generator
Build Content Security Policy headers with an interactive visual builder. Protect your site from XSS and injection attacks.
Fallback for all fetch directives
Valid sources for JavaScript
Valid sources for stylesheets
Valid sources for images
Valid sources for fonts
Restricts URLs for fetch, XHR, WebSocket
Valid sources for audio/video
Valid sources for frames
Valid sources for plugins (object, embed)
Restricts URLs for <base> element
Restricts URLs for form submissions
Valid parents for framing (replaces X-Frame-Options)
How to Use the CSP Generator
- Select the directives you need (default-src, script-src, style-src, img-src, etc.).
- Configure allowed sources for each directive (self, specific domains, nonces, hashes).
- Preview the generated Content-Security-Policy header in real time.
- Copy the CSP header and add it to your server configuration or meta tag.
- Test your CSP in report-only mode before enforcing to avoid breaking your site.
What is Content Security Policy (CSP)?
Content Security Policy is an HTTP response header that allows you to control which resources the browser is allowed to load for a given page. By defining a whitelist of trusted content sources, CSP acts as a powerful defense layer against Cross-Site Scripting (XSS), clickjacking, and other code injection attacks. When a CSP is active, the browser blocks any resource that does not match the policy, preventing injected scripts from executing. A CSP consists of directives that control specific resource types. The default-src directive sets the fallback policy for all resource types. More specific directives like script-src (JavaScript), style-src (CSS), img-src (images), connect-src (AJAX/WebSocket), font-src (fonts), and frame-src (iframes) override the default for their specific resource type. Source values include 'self' (same origin), specific domains, 'unsafe-inline', 'unsafe-eval', nonces, and hashes. Implementing a strict CSP is one of the most effective measures against XSS. A properly configured CSP with nonce-based script-src eliminates the vast majority of XSS vectors, even when input validation fails. Start with Content-Security-Policy-Report-Only to monitor violations without blocking content, review the reports to identify legitimate resources, then switch to enforcement mode. Avoid 'unsafe-inline' and 'unsafe-eval' whenever possible, as they significantly weaken the protection CSP provides.
Frequently Asked Questions
Content-Security-Policy enforces the rules and blocks violating resources. Content-Security-Policy-Report-Only monitors violations and sends reports to a designated endpoint without blocking anything. Always deploy in report-only mode first to identify legitimate resources that would be blocked, then switch to enforcement after refining the policy.
The 'unsafe-inline' directive allows execution of inline scripts and styles, which is exactly what XSS attacks inject. Allowing it essentially disables CSP protection against XSS. Instead, use nonces (script-src 'nonce-randomvalue') or hashes to allow specific inline scripts while blocking all others.
A nonce is a random, single-use value generated by the server for each response. The server adds the nonce to the CSP header (script-src 'nonce-abc123') and to allowed script tags (script nonce='abc123'). Only scripts with the matching nonce execute. Since attackers cannot predict the nonce, injected scripts are blocked even if they are inline.
The frame-ancestors directive controls which origins can embed your page in iframes. Setting frame-ancestors 'none' prevents all framing, while frame-ancestors 'self' allows only same-origin framing. This is the CSP replacement for the older X-Frame-Options header and provides more granular control over framing permissions.