Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:
Free CSP Header Generator
Build a Content-Security-Policy header visually by adding directives and allowed sources, with live warnings about common misconfigurations. It helps frontend and security teams design a Content-Security-Policy header that reduces script, style, and resource injection risk.
Why configure a Content-Security-Policy
CSP is one of the most effective browser-enforced defenses against cross-site scripting: instead of trying to sanitize every possible way an attacker might inject a script, you declare up front exactly which origins are allowed to supply scripts, styles, images, fonts, and other resources, and the browser blocks everything else — including inline scripts unless explicitly allowed. Getting the policy right by hand is fiddly, since each directive has its own syntax and a single typo can silently allow more than intended or break legitimate functionality.
How to use this generator
Add a directive, choose or type the sources it should allow, and use the quick-add buttons for common keywords like 'self' and 'none'. The tool flags common issues as you go — combining 'none' with other sources, allowing 'unsafe-inline' or 'unsafe-eval', or wildcarding a directive to any origin — then copy the finished header value into your server configuration.
Common use cases
- Drafting a starting CSP for a new project before tightening it based on real console violation reports
- Reviewing an existing policy for accidental use of unsafe-inline or unsafe-eval
- Working out the right script-src value when adding a new third-party analytics or widget script
- Documenting the intended security header configuration for a code review or security audit
Everything is assembled locally in your browser — no part of your configuration is sent to a server.
How to use CSP Header Generator for related tasks
Choose the directives, add trusted sources, generate the CSP header, and test it in report-only mode before enforcing a restrictive policy.
Related tools: REST API Tester, Meta Tag / Open Graph Preview.
Frequently asked questions
What does a Content-Security-Policy header actually do?
CSP tells the browser which sources are allowed to load scripts, styles, images, fonts, and other resources on your page. It's a defense-in-depth measure against cross-site scripting (XSS) and data injection attacks — even if an attacker manages to inject a <script> tag, the browser refuses to execute it if its source isn't allowed by the policy.
Why does the tool warn me about 'unsafe-inline'?
'unsafe-inline' allows inline <script> and <style> tags and inline event handlers to run, which defeats a large part of what CSP protects against — an attacker who can inject HTML can also inject an inline script. It's sometimes unavoidable for legacy code, but the warning is there so you make that trade-off knowingly rather than by accident.
How do I actually apply this header?
Send it as an HTTP response header named Content-Security-Policy from your server or CDN configuration, or add it as a <meta http-equiv="Content-Security-Policy" content="..."> tag in your HTML (with some restrictions — frame-ancestors and a few other directives only work via the HTTP header, not the meta tag).
Is my configuration sent anywhere?
No — the header string is assembled entirely in your browser from the rules you enter. Nothing is sent to a server.
Why did a CSP header break my site?
A missing source or overly strict directive can block scripts, styles, fonts, or images; inspect browser violations and add only the source the page truly needs.