CSP Builder & Analyzer
Paste a Content-Security-Policy to have every directive explained and its weak spots flagged — unsafe-inline, wildcards, unsafe-eval and more — or build a strict policy from a safe baseline by ticking only what your site needs. Everything runs in your browser.
New to this? Read the CSP guide →
Everything runs locally in your browser — no policy is uploaded.
How to use the CSP tool
- Analyze: paste an existing Content-Security-Policy header value. Each directive is explained, and weak or dangerous settings are flagged with the reason and a fix.
- Build: start from a strict baseline and tick only what your site genuinely needs — the policy updates live.
- Roll it out with Content-Security-Policy-Report-Only first so violations are reported but not blocked, then switch to the enforcing header once it is clean.
What CSP protects against
A Content Security Policy is a browser allowlist for where a page may load scripts, styles, images, frames and other resources. Its main job is to blunt cross-site scripting (XSS): even if an attacker injects a <script>, a strict policy stops the browser executing it. It also mitigates clickjacking (via frame-ancestors) and mixed content.
The pitfalls it flags
The most common mistake is 'unsafe-inline' in script-src, which re-enables exactly the inline scripts CSP exists to block. Wildcards (*), 'unsafe-eval', and data: in script-src similarly weaken the policy. Prefer nonces or hashes for the inline scripts you actually need — the analyzer notes when a nonce or hash is present, since modern browsers then ignore 'unsafe-inline'.
Frequently asked questions
What is a Content-Security-Policy?
It is an allowlist the browser enforces for where a page may load scripts, styles, images, frames and other resources. Its main job is to stop cross-site scripting: with a strict script-src, an injected script simply will not run. It also mitigates clickjacking and mixed content.
Why is unsafe-inline flagged as dangerous?
Adding unsafe-inline to script-src re-enables inline scripts — exactly what CSP blocks to prevent XSS. Use per-request nonces or hashes for the inline scripts you actually need; when one is present, browsers ignore unsafe-inline, so it is safe only as an old-browser fallback.
How should I roll out a CSP without breaking my site?
Deploy it first with the Content-Security-Policy-Report-Only header, which reports violations without blocking them. Watch the reports, fix what your real pages need, then switch to the enforcing header once it is quiet.
Is my policy uploaded?
No. The analyzer and builder are pure string processing in your browser — nothing you paste is sent anywhere.