Tool guide
CSP Header Checker
A CSP header checker is useful because Content-Security-Policy is powerful, but it is also one of the easiest headers to get wrong.
What To Look For
First check whether the site sends Content-Security-Policy or Content-Security-Policy-Report-Only on the final response.
Then review whether the policy has meaningful directives such as default-src, script-src, object-src, base-uri, and frame-ancestors.
Avoid Breaking Pages
For an existing site, start in report-only mode when possible. It helps you see violations without blocking real visitors.
Add sources narrowly. If an image is blocked, adjust img-src; if an API call is blocked, adjust connect-src instead of loosening the whole policy.
What To Do Next
If CSP is missing, start with a simple baseline and map the resources your page actually uses.
If CSP is present but weak, remove broad wildcards over time and replace unsafe inline patterns with nonces, hashes, or bundled code where practical.
Common questions
Does a CSP header checker validate every directive?
It can show whether the header is present and help you inspect the policy, but you still need browser testing for real page behavior.
Should CSP be report-only first?
For existing sites, yes. Report-only mode is safer while you discover what the page needs to load.
Is unsafe-inline always bad?
It weakens CSP. Some sites use it temporarily, but nonces, hashes, or moving inline code are better long-term fixes.
Can CSP block analytics or fonts?
Yes. Add trusted analytics, font, image, and API sources to the specific directives that need them.