Content Security Policy Builder

How to use

1. Start from the defaults, which are a strict policy that works for most static sites.
2. Add the origins your page genuinely loads from, one directive at a time.
3. Deploy it as report-only first, watch what breaks, then enforce.
4. Copy the response header — the meta tag is a fallback, not the preferred form.

Features

• All the directives that matter, with the common keywords listed.
• Warns about 'unsafe-inline', 'unsafe-eval', wildcards and a missing default-src.
• Says which directives a meta tag cannot carry, rather than emitting one that half works.
• Reads an existing policy back so it can be edited.
• Runs entirely in your browser.

Frequently asked questions

Why is 'unsafe-inline' such a problem?

Because an injected script is inline script. A policy that allows inline script allows the attack it was written to stop — the header is present, the protection is not. Use a nonce (a random value on your own script tags, regenerated per response) or a hash of each script's contents.

Header or meta tag?

Header, wherever you can set one. A meta tag cannot express `frame-ancestors` or report-only mode, and it only applies to content after the tag — anything the parser saw first is already unprotected. The meta form is for when you genuinely cannot touch the server.

How do I roll one out without breaking the site?

Report-only first. The browser reports what the policy would have blocked without blocking it, so you can find the resources you forgot before your users do. Switch to enforcing once the reports go quiet — and note that report-only on its own protects nothing, which is why it is flagged here.

Related tools