Content Security Policy Generator
Build a Content-Security-Policy header directive by directive, or paste an existing policy to check it for common misconfigurations. Everything runs in your browser — nothing is uploaded.
| Directive | 'self' | 'none' | 'unsafe-inline' | 'unsafe-eval' | data: | https: | Custom domains (CSV) |
|---|
| Directive | Sources |
|---|
About this tool
The builder covers the ten most commonly deployed CSP directives and the standard keyword sources; it will not stop you from writing a permissive policy, so review the generated header before shipping it and roll it out with Content-Security-Policy-Report-Only first to catch breakage. The analyzer flags well-known misconfigurations — unsafe-inline in script-src, wildcard sources, a missing default-src fallback — but it is a quick sanity check, not an exhaustive security audit of your policy.
Policies you build or paste never leave the page — there is no server, no upload, and no tracking of tool inputs.
Frequently asked questions
Why is 'unsafe-inline' bad in a CSP?
Because it re-enables the very thing CSP exists to stop. Most XSS payloads are injected inline scripts or event handlers; 'unsafe-inline' in script-src tells the browser to run all of them, reducing the policy to decoration. The modern alternative is a per-response nonce or a hash of each inline script, often combined with 'strict-dynamic' — that way only the inline code you shipped can execute.
Should I set CSP as an HTTP header or a meta tag?
Prefer the header. Several parts of CSP simply do not work in a meta tag: frame-ancestors (the clickjacking defense), sandbox, and violation reporting (report-uri/report-to) are all ignored there. A meta tag also only takes effect once the parser reaches it, so earlier resources are unprotected. Use the meta version only when you cannot touch server configuration, such as on static hosting without header support.
What is Content-Security-Policy-Report-Only?
A twin header that evaluates the policy and reports violations without blocking anything. It is the standard rollout path: ship your intended policy as Report-Only with a report-to or report-uri endpoint, watch what would have broken in real traffic for a week or two, fix the legitimate cases, then promote it to the enforcing header. You can even run both headers at once — one enforcing a loose policy, one testing a stricter one.
Does CSP stop all XSS?
No — it is a mitigation layer, not a cure. CSP can be undermined by 'unsafe-inline', overly broad sources, JSONP endpoints or Angular-style gadgets on allowlisted CDNs, and it does nothing about non-script injection like HTML or CSS abuse. Treat it as defense-in-depth: keep escaping output and sanitizing input, and let a strict CSP catch what slips through.
How do I see which security headers my site currently sends?
Check the response headers in your browser's DevTools network tab, or paste them into the HTTP Headers Analyzer on this site — it explains each header and audits the security-relevant ones, including CSP, HSTS, X-Content-Type-Options, and Referrer-Policy. That makes a good before/after check when you deploy a policy built here.