CSP Header Builder
Build Content-Security-Policy headers visually. Toggle directives, add trusted sources, apply presets, and copy the header, meta tag, nginx, or Apache config.
Presets
Directives
Fallback for other fetch directives
Valid sources for JavaScript
Valid sources for stylesheets
Valid sources for images
Valid sources for fonts
Valid targets for fetch, XHR, WebSocket
Valid sources for <frame> and <iframe>
Valid sources for <audio> and <video>
Valid sources for <object> and <embed>
Valid sources for Worker and SharedWorker
Valid sources for web app manifests
Valid targets for form submissions
Valid parents that can embed this page
Restricts URLs for <base> element
Upgrade HTTP to HTTPS
Block all mixed content
Output
Content-Security-Policy: default-src 'self'
<meta http-equiv="Content-Security-Policy" content="default-src 'self'" />
add_header Content-Security-Policy "default-src 'self'";
Header set Content-Security-Policy "default-src 'self'"
What Is Content-Security-Policy?
Content-Security-Policy (CSP) is an HTTP response header that instructs the browser on which sources of content — scripts, styles, images, fonts, frames, and more — are permitted to load on your page. It is one of the most effective defenses against Cross-Site Scripting (XSS) attacks.
A typical CSP value looks like: default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'. Each directive targets a specific resource type, and the default-src directive acts as a fallback for any type not explicitly specified.
Common CSP Directives Explained
| Directive | Controls |
|---|---|
| default-src | Fallback for all fetch directives not explicitly set |
| script-src | JavaScript files, inline scripts (with nonce/hash) |
| style-src | CSS stylesheets, inline styles (with nonce/hash) |
| img-src | Images, favicons, canvas sources |
| connect-src | fetch(), XHR, WebSocket, EventSource connections |
| font-src | Web fonts loaded via @font-face |
| frame-src | Sources for <frame> and <iframe> elements |
| object-src | Sources for <object>, <embed>, <applet> |
| frame-ancestors | Which origins can embed this page in a frame (replaces X-Frame-Options) |
| form-action | Valid targets for <form> action submissions |
| upgrade-insecure-requests | Instructs browser to upgrade http:// requests to https:// |
Deploying CSP Without Breaking Your Site
The biggest risk when adding CSP is breaking your own site by blocking resources you depend on. The safest deployment strategy is to start with Report-Only mode. Set the Content-Security-Policy-Report-Only header with a report-uri directive pointing to your violation collector. Browse your site normally, check the reports, and add any missing sources to your policy. Once violations stop appearing in reports, switch to the enforcing Content-Security-Policy header.
Common breaking points: third-party chat widgets (add their script domain to script-src), Google Fonts (add fonts.googleapis.com to style-src and fonts.gstatic.com to font-src), analytics scripts, and CDN-hosted libraries.
Frequently Asked Questions
What is Content-Security-Policy?
Content-Security-Policy (CSP) is an HTTP response header that tells browsers which sources of content are allowed to load on a page. By specifying a policy, you prevent cross-site scripting (XSS) attacks, data injection, and clickjacking. For example, a policy that only allows scripts from 'self' means the browser will refuse to run scripts loaded from any other origin.
Why is 'unsafe-inline' dangerous?
The 'unsafe-inline' keyword allows inline <script> tags, onclick attributes, and inline <style> blocks. This defeats a major purpose of CSP — blocking injected inline scripts in XSS attacks. If an attacker can inject an inline script into your page, 'unsafe-inline' means it will run. Instead, use nonces (a one-time token per request) or hashes for specific inline scripts you control.
How do I test my CSP without breaking my site?
Use Report-Only mode first. Switch the toggle in this tool to enable Content-Security-Policy-Report-Only. This header reports CSP violations to a report-uri endpoint without enforcing the policy, so your site continues to work. Collect reports to identify all blocked resources, refine your policy, then switch to the enforcing header.
What is CSP report-only mode?
Content-Security-Policy-Report-Only is a non-enforcing version of the CSP header. Violations are reported (to a URL you specify with report-uri or report-to) but content is still allowed to load. This is the recommended way to deploy CSP — test with report-only first, fix violations, then switch to the full Content-Security-Policy header.
What is a CSP nonce and when should I use it?
A nonce is a cryptographically random token generated per HTTP request and included in both the CSP header (e.g., 'nonce-abc123') and in a script tag's nonce attribute (<script nonce="abc123">). The browser only runs scripts whose nonce attribute matches the one in the CSP. Nonces allow specific inline scripts while keeping 'unsafe-inline' disabled, giving you security without needing to move all JavaScript to external files.