Loading the interactive tool… It runs in your browser — if it doesn't appear, enable JavaScript.
Configure each directive, pick a preset for a common stack, and copy a ready-to-use Content-Security-Policy header. It also audits what you've built and flags the settings that make a policy decorative rather than protective.
Two directives are *not* covered by `default-src` and are the ones most often missed: `frame-ancestors`, which prevents clickjacking and replaces X-Frame-Options, and `base-uri`, without which an injected `<base>` tag can redirect every relative URL on the page. A policy that omits both looks thorough and isn't.
Frequently asked questions
Why does the tool warn about 'unsafe-inline'?
Because it defeats the main purpose of CSP. The reason script-src stops cross-site scripting is that an injected `<script>` tag won't execute — 'unsafe-inline' allows exactly that, so an attacker who can inject markup can run code. Use a nonce or hash for the inline scripts you genuinely need.
What should I do first when adding CSP to an existing site?
Deploy in Report-Only mode and watch the violation reports for a week or two. A CSP that breaks your own site gets switched off in a hurry, which leaves you with no policy at all — considerably worse than a slightly loose one that stays on. Tighten it once you know what actually loads.
Does default-src cover everything?
No, and this is the most common misunderstanding. It's a fallback for fetch directives like script-src and img-src, but frame-ancestors, base-uri, form-action, sandbox and report-uri are not fetch directives and are not covered. Set them explicitly.
Is a CSP enough on its own?
No — it's defence in depth, not a substitute for escaping output and validating input. It limits the damage of an injection you failed to prevent. Treat a CSP violation report as evidence of a bug to fix, not as the control working as intended.