CSP Header Builder
Pick a starting point, then set which sources are allowed for scripts, styles, images and more. The header is built for you and graded as you go.
Worked examples
A strict starting policy
Preset: Strict, with scripts, styles, images, fonts and requests from my own site
default-src 'none'; script-src 'self'; style-src 'self'; img-src 'self'; font-src 'self'; connect-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'none'
Add hosts for any outside services you use, then grade the result with the evaluator.
About CSP Header Builder
A Content-Security-Policy is a header that tells the browser where a page may load content from. If an attacker finds a way to put a script into your page, a good policy stops the browser running it, because the script does not come from a place you allowed. It is one of the most effective protections against cross-site scripting, but the format is fiddly: directives, keywords in single quotes, schemes and hosts all have to be written exactly right.
This builder lets you choose rather than type. Each row is one directive, such as script-src for scripts or img-src for images, and you pick whether nothing is allowed, only your own site, any HTTPS address or anywhere, then add extra hosts for services you use. Options cover nonces, upgrading insecure requests and report-only mode. As you change settings the header is rebuilt and graded with the same checks as the evaluator, so you can see at once when a choice weakens the policy, and a short list explains what each part you used does.
How to use CSP Header Builder
- Pick a starting point from the list, or begin with every row set to Not set.
- For each kind of content choose what is allowed and add any extra hosts, separated by spaces.
- Tick the options you need, such as nonces, upgrading insecure requests or report only mode.
- Copy the finished header and add it in your hosting settings or web server.
Common uses
- Adding a first policy to a small business site
- Tightening a policy before a security review
- Learning what each directive does by changing it
- Trying a report-only policy before enforcing it
Frequently asked questions
What is report-only mode?
The header name changes to Content-Security-Policy-Report-Only. The browser does not block anything but records what it would have blocked, and sends reports if you gave an address. It is the least risky way to find out what a new policy would break before you enforce it.
Why is default-src not enough on its own?
Default-src is the fallback for most content types, but some directives never fall back to it. Base-uri, form-action and frame-ancestors have to be set on their own, which is why the builder shows them as separate rows.
What is a nonce and how do I use it?
A nonce is a random value, new for every page load, that you put in the policy and in each inline script tag you trust. The browser runs only inline scripts that carry the matching value. It needs support in your server code, and a fixed value gives no protection.
Can I put the policy in a meta tag?
Mostly, but a meta tag cannot use frame-ancestors, report-uri or the report-only form. A header is the better choice wherever you can set one.
My site broke after I added the policy. What now?
Switch to report-only mode, open the site and read the browser console to see what was blocked. Then add the missing hosts or move inline code into files. Make changes one at a time and test between each.