Content Security Policy Generator
Build a Content-Security-Policy header directive-by-directive with quick-start presets.
Fallback for all fetch directives
JavaScript sources
Stylesheet sources
Image sources
Font sources
Fetch / XHR / WebSocket
Audio and video sources
<object>, <embed> sources
<iframe> sources
Who may embed this page
Form submission targets
Restricts <base> href values
Upgrade HTTP sub-resources to HTTPS (no value needed)
Block any HTTP sub-resources (no value needed)
URL to send violation reports (deprecated; prefer report-to)
How Content Security Policy works
Content Security Policy (CSP) is an HTTP response header that instructs browsers to only load resources from trusted origins. A strict policy using default-src 'self' with nonces for inline scripts significantly reduces the impact of cross-site scripting (XSS) attacks. Start with Content-Security-Policy-Report-Only to monitor violations before enforcing the policy.
For other security headers see the HTTP Security Header Generator. For cookie security, use the HTTP Cookie Builder.
Built and maintained by Meet Shah · Last updated
What this tool is used for
- Building a first policy in report-only mode to see what a page actually loads.
- Tightening an existing policy directive by directive.
- Working out which directives a third-party embed requires.
- Producing a policy for a static site with a known asset list.
- Comparing a header form against the meta tag form.
Frequently Asked Questions
- What does a CSP actually stop?
- Execution of resources you did not allow. Its headline effect is on cross-site scripting: an injected `<script>` is not run because the policy does not permit inline scripts. It is a second line of defence — it limits what an injection can do, not whether one can happen.
- Which directive should I get right first?
- `script-src`, followed by `object-src: 'none'` and `base-uri: 'self'`. Those three carry most of the protection. A policy with a strict `img-src` and a permissive `script-src` looks thorough and defends almost nothing.
- How do nonces work?
- The server generates a random value per RESPONSE, puts it in the policy as `'nonce-xyz'` and on each script tag it wants to allow. An injected script has no way to know the value, so it is refused. The per-response part is essential — a reused nonce is no better than allowing inline scripts.
- How do I find out what a policy would break?
- Deploy it as `Content-Security-Policy-Report-Only` with a reporting endpoint. Nothing is blocked, every would-be violation is reported, and you get a real inventory of what the site loads — usually including several things nobody remembered adding.
- Does a CSP replace escaping user input?
- No. It is defence in depth: escaping prevents the injection, the policy limits the damage when escaping is missed. A site that relies on CSP alone is one misconfigured header away from being unprotected, and headers get changed by people who are not thinking about XSS.
Common errors and gotchas
- Deploying an enforcing policy without a report-only trial, which breaks the page for every visitor at once.
- Including `unsafe-inline` in script-src, which removes most of the protection the policy provides.
- Forgetting `default-src`, so directives you did not name fall back to allowing everything.
- Overlooking that some directives cannot be set via the meta tag at all.
- Assuming a policy stops all XSS, when it limits the damage rather than preventing the injection.