CSP Header Validator
Paste a Content-Security-Policy header value to validate its directives and source values in one pass. Detects risky settings like unsafe-inline, a missing default-src fallback, and typos in directive names, and shows every directive's allowed sources in a visual breakdown.
Inspecting the contents of a CSP header
A Content-Security-Policy is a single long string separated by semicolons, and following it by eye makes it easy to miss the risky parts. This tool takes the value you paste, breaks it into directives and sources, surfaces dangerous settings, missing declarations and misspellings, and lays out what each directive actually permits.
**A misspelt directive name is the most troublesome case of all.** Browsers silently ignore directives they do not recognise, so writing `scipt-src` in place of `script-src` **raises no error whatsoever while that part of the policy goes on doing nothing at all.** Just as easily overlooked is the absence of `default-src`: without it, any directive you did not spell out goes unrestricted and a hole opens in the defence. And putting `unsafe-inline` into script-src **all but nullifies the blocking of inline scripts, which is the chief reason for adopting CSP in the first place.**
How to use it
- Paste in the value of the CSP header Enter a string of the form `default-src 'self'; script-src ...` exactly as it stands.
- Try the samples first A good example and a bad one are provided, so you can see how the judgements differ before you start.
- Read the points raised **`unsafe-inline`, a missing `default-src` and misspellings are all called out.**
- Review the permitted sources per directive You can see at a glance where loading is allowed from.
Tips for getting more out of it
- CSP is normally delivered as an HTTP response header, but it can also be set via a
<meta http-equiv="Content-Security-Policy">tag (though directives like report-uri have no effect there). - Before rolling CSP out in production, try the Content-Security-Policy-Report-Only header first — it only collects violation reports, letting you gauge the impact on existing functionality without breaking anything.
- Wildcards (*) and 'unsafe-inline' make development easier, but they undercut most of CSP's XSS protection. Always tighten a loose policy before shipping to production.
- Repeating the same directive twice does not merge the values — only the first occurrence takes effect. To add or override sources, keep everything in a single directive.
- Your browser's DevTools console prints blocked resources as a red "Refused to load..." message, so it is the first place to check when debugging a CSP that is too strict.
Where it comes in useful
Introducing a CSP for the first time
You can confirm that the policy you wrote does what you meant before it goes anywhere near production.
Taking stock of an existing policy
**A policy grown by accretion tends to keep permissions for domains nobody uses any more.**
Moving from report-only to enforcement
A value tried out under `Content-Security-Policy-Report-Only` can be inspected before it is enforced.
Assisting a code review
Paste the amended policy and confirm that it has not been weakened.
CSP terms
- Directive
- An entry such as `script-src` or `img-src` that **states where a given class of resource may be loaded from.**
- Default-src
- The fallback for any directive not stated individually. **Leave it out and every class you did not spell out goes unrestricted.**
- 'self'
- A source expression permitting loads from the same origin only.
- 'unsafe-inline'
- A source expression permitting scripts and styles written directly into the HTML. **It all but forfeits the defence against XSS, so replacing it with a nonce or a hash is advised.**
- Nonce
- A scheme that writes a single-use random value into both the script tag and the policy so the two correspond. It is the safe way to permit inline code.
- Frame-ancestors
- A directive naming who may embed your site in a frame. **It is the successor to X-Frame-Options.**
FAQ
Side Note — Why CSP exists: escaping alone was never enough to stop XSS
Content Security Policy traces back to an idea Robert Hansen floated around 2004, which Mozilla engineer Brandon Sterne then turned into a formal specification starting around 2008, leading to the first W3C Candidate Recommendation (Level 1) in 2012. Cross-site scripting (XSS) was one of the most pressing web vulnerabilities of the era, and it became clear that relying solely on developer diligence — "escape every output correctly" — was not a robust enough defense. CSP was designed as a defense-in-depth mechanism that lets the browser itself enforce restrictions on where scripts can come from.
CSP Level 2 introduced nonce- and hash-based allowances for inline scripts, letting sites permit specific inline code without resorting to 'unsafe-inline'. Level 3 then added 'strict-dynamic', which automatically trusts scripts dynamically loaded by an already-trusted script, dramatically cutting the maintenance burden of host-based allowlists on large sites.
Google has continued rolling out strict, nonce-based CSP across its own large-scale services, and published research from that effort concluding that host-based allowlists are frequently bypassable, while nonce- or hash-based policies are far more effective in practice. That finding is now widely cited as CSP best practice, underscoring that the real design decision is not just "which values to ban" but "which allowlisting strategy to build on" in the first place.