Free Tool - No Signup Required

CSP Scanner

Check your website's Content-Security-Policy. We crawl your site, analyze your current CSP for weaknesses, inventory every resource your pages load — and generate a starter policy that fits your site.

Crawls up to 20 pages — can take ~30-45 seconds.

What a static scan can't see

This scanner reads your HTML, so it finds the scripts, styles, images, fonts and frames your pages reference directly. It cannot see resources that only load when JavaScript runs: API calls and websockets (connect-src), lazy-loaded widgets, tag-manager payloads, or A/B-test scripts. A policy built only from a crawl may block those when you enforce it.

For a runtime-accurate CSP, use the account-based CSP Monitor: create a free account, deploy the Report-Only policy with our reporting endpoint, collect real browser violation reports from your actual visitors, and get a strict CSP based on reality instead of a snapshot.

Set up CSP monitoring

Why scan your Content-Security-Policy?

A Content-Security-Policy (CSP) is the strongest browser-side defence against cross-site scripting (XSS). It is an allowlist: the browser only loads scripts, styles, images and other resources from the origins your policy names, and refuses everything else — including whatever an attacker manages to inject.

Most sites either have no CSP at all, or a policy weakened to the point of uselessness by 'unsafe-inline' and wildcards. This content security policy checker finds both problems: it analyzes your current policy against known CSP weaknesses, and it crawls your site to discover what your pages actually load — so the policy it generates is grounded in evidence, not guesswork.

The hard part of deploying a CSP has never been the syntax — it is knowing every origin your site depends on, so the policy does not break the site the day you enforce it. That is exactly what the crawl, the per-directive resource inventory and the Report-Only-first rollout in this CSP analyzer are for.

Frequently Asked Questions

What is a Content-Security-Policy (CSP)?
A Content-Security-Policy is an HTTP header that tells the browser exactly which scripts, styles, images and other resources a page is allowed to load, and from where. It is the strongest browser-side defence against cross-site scripting (XSS): even if an attacker manages to inject a script tag into your page, the browser refuses to run it unless your policy allows it.
What does this CSP scanner check?
It crawls up to 20 pages of your site, reads any Content-Security-Policy header or meta tag it finds, and flags known weaknesses like unsafe-inline, wildcards and missing directives. At the same time it builds an inventory of every external origin your pages actually load scripts, styles, images, fonts and frames from — and uses that inventory to generate a starter CSP tailored to your site.
The scanner says my site has no CSP. How bad is that?
It means any injected script runs completely unrestricted — there is no browser-side safety net against XSS at all. The good news: this scan already generated a starter policy from the resources your site really uses. Deploy the Report-Only variant first, watch for violations, then switch to enforcing.
What is the difference between the report-only and enforce policies?
The Content-Security-Policy-Report-Only header tells the browser to log (and report) anything the policy would have blocked, without actually blocking it. That lets you trial a policy on a live site with zero risk of breaking it. Once the violation reports come back clean, you rename the header to Content-Security-Policy and the same policy starts enforcing.
Is the generated CSP safe to deploy as-is?
Deploy it in Report-Only mode first, always. The policy is built from what a static crawl observed, but a crawl cannot see resources that are only loaded by JavaScript at runtime — API calls (connect-src), lazy-loaded widgets, A/B-test scripts, websockets. Enforcing immediately could block those. Report-Only mode reveals them safely; a CSP based on real browser violation reports closes the gap completely.
Why does the scanner flag my inline scripts?
Inline <script> blocks are exactly what an XSS attacker injects, so a policy that allows them ('unsafe-inline') protects you against almost nothing. The generated policy never adds 'unsafe-inline' for scripts. To keep your own inline scripts working, either move them into .js files served from your own origin, or add a per-request nonce to each script tag and to the policy.
Why does the scanner crawl multiple pages instead of just the homepage?
Different pages load different resources — your checkout might use a payment provider script that the homepage never touches. A policy built from the homepage alone would break those pages the moment you enforce it. Crawling up to 20 same-origin pages catches far more of what your site really needs.
Where do I add the generated policy?
Add it as an HTTP response header in your web server, CDN or framework — Content-Security-Policy-Report-Only to trial it, Content-Security-Policy to enforce it. The CSP Generator on this site can turn the policy into ready-to-paste Nginx, Apache, Caddy and Cloudflare snippets, and lets you fine-tune individual directives.

CSP Generator

Build a Content-Security-Policy by hand with live preview.

Security Headers Generator

Generate HSTS, CSP and the full security header set.

HTTP/3 Checker

Test Alt-Svc, the HTTPS DNS record, and a live QUIC probe.