CSP Header Generator
Build a Content-Security-Policy header directive by directive — output for raw header, .htaccess, Nginx, meta tag or PHP.
This tool runs 100% in your browser. Your data is never uploaded, stored, or logged.
Content-Security-Policy
About this tool
A good Content-Security-Policy is one of the strongest defenses against XSS — and one of the easiest headers to get wrong. This generator lets you fill in each directive (default-src, script-src, img-src…) and assembles a syntactically correct policy for your chosen deployment target.
Sensible protections like object-src 'none' and base-uri 'self' are on by default, and risky values like 'unsafe-inline' in script-src trigger a warning.
How to use it
- Fill in the sources for each directive ('self', domains, data: …).
- Keep the recommended toggles on unless you have a reason not to.
- Pick the output format: raw header, .htaccess, Nginx, HTML meta or PHP.
- Deploy, then watch your browser console for violation reports while testing.
Useful ways to apply it
- Adding a first CSP to a site that has none.
- Locking scripts to your own domain plus a known CDN.
- Preventing clickjacking via frame-ancestors.
- Migrating an old X-Frame-Options setup to modern CSP.
Frequently asked questions
What does default-src do?
It's the fallback for every fetch-type directive you don't set explicitly. Starting with default-src 'self' and loosening specific directives is the classic safe pattern.
Why is 'unsafe-inline' flagged?
Allowing inline scripts largely defeats CSP's XSS protection. Prefer moving scripts to files, or use nonces/hashes if inline is unavoidable.
Why doesn't frame-ancestors work in a meta tag?
The spec ignores frame-ancestors (and report-uri) in meta-delivered policies — it must be sent as a real HTTP header. The tool notes this when you pick meta output.
Privacy
This tool runs 100% in your browser. Your data is never uploaded, stored, or logged.