Loading…
Loading…
Paste any URL you're authorized to test. Scorifya fetches the response and shows your Content-Security-Policy alongside the rest of your security headers, so you can see if a CSP is present and how strong it is.
Free tool
Content-Security-Policy is the header that limits where a page can load scripts, styles, and other content from, which shrinks the blast radius of cross-site scripting and injected skimmers. It is also the easiest security header to get half-right: a policy that still allows unsafe-inline, uses a bare wildcard, or runs in report-only forever does far less than it looks like it does. A checker tells you whether a CSP is present, whether it is enforcing, and where its weak spots are.
Paste any URL you're allowed to test. Scorifya fetches the response, reports your Content-Security-Policy, present or absent, enforcing or report-only, and flags common weaknesses like unsafe-inline, unsafe-eval, and wildcard sources. CSP sits inside the broader 0 to 100 hardening score, so you see the headers around it too.
This page is written for people searching for CSP checker—same tool as the homepage, with context for that query.
How we differ from deep TLS graders, browser-focused posture tools, and header-only checkers: read the comparison.
Illustrative snapshots of what a report can look like—paste your URL above for a live score on your site.
Example A: no CSP at all
TLS and most headers are fine, but no Content-Security-Policy is sent, so the browser falls back to defaults and the XSS blast radius stays larger than it needs to be.
Content-Security-Policy missing
No CSP means the browser enforces no source restrictions on scripts and styles. Start with a report-only policy so you can see what would break before enforcing.
Example B: CSP present but weak
A Content-Security-Policy is enforcing, but it allows unsafe-inline for scripts, which is the single biggest weakness in most production CSPs. Removing it pushes the score up.
CSP allows unsafe-inline for scripts
Move inline scripts to nonces or external files so you can drop unsafe-inline. Until then, an injected inline script still runs.
Broad wildcard in a source list
A bare wildcard or a large host allows more than you intend. Tighten it to the specific origins your pages actually load.
Roll out CSP in report-only mode first
Ship Content-Security-Policy-Report-Only with a logging endpoint and watch the violations for a release cycle. This is what prevents the broken-homepage outcome that makes teams abandon CSP. Once the reports go quiet, switch the header name to enforcing.
Remove unsafe-inline with nonces
unsafe-inline for script-src is the most common weakness in real CSPs. Generate a per-request nonce, add it to your inline scripts, and reference it in the policy so you can drop unsafe-inline entirely.
Replace wildcards with explicit allowlists
Inventory the exact origins your pages load scripts, styles, fonts, and frames from, then list those instead of a bare wildcard or an over-broad host. The tighter the list, the less an injection can reach.
Set frame-ancestors to control framing
frame-ancestors in the CSP is the modern way to prevent your pages from being embedded in attacker-controlled iframes, alongside or in place of X-Frame-Options.
Re-scan after every policy change
Headers update on the very next response after a deploy. Re-scan immediately to confirm the policy is enforcing with the directives you expect.
For weights and penalties behind each category, see How Scorifya works.
Background explainers for what this tool checks.
A Content-Security-Policy (CSP) is a response header that tells the browser which sources a page is allowed to load scripts, styles, images, fonts, and frames from. By restricting those sources, a CSP limits what an injected or cross-site script can do, which is one of the strongest defenses against cross-site scripting and page-skimming attacks.
The most common weaknesses are: allowing unsafe-inline for scripts (so injected inline scripts still run), allowing unsafe-eval, using a bare wildcard or an over-broad host in a source list, and leaving the policy in report-only mode permanently so it never actually blocks anything. A CSP that avoids those is doing real work.
Start in report-only so you can see what the policy would block without breaking the page, fix or allow whatever shows up in the reports, then switch to the enforcing Content-Security-Policy header. Shipping straight to enforcing is what breaks sites and makes teams give up on CSP.
Yes. Checking your CSP (and running the full Scorifya scan) is free for any URL you're authorized to test. Pro adds higher rate limits, scheduled re-scans, watch lists with alerts, and exports.
No. Scorifya only fetches public, unauthenticated URLs. CSP can differ on authenticated routes, so test those during your own staging passes.
More detail on limits and billing: FAQ.
TLS, HTTPS & redirects
Valid certificates, modern TLS, and clean HTTP→HTTPS upgrades. We also probe whether legacy TLS 1.0/1.1 are still accepted.
Security headers
CSP, HSTS, and related headers reduce common browser-side attack surfaces and clickjacking risk.
DNS & email (passive)
SPF, DMARC, a few DKIM selectors, MX, and whether common subdomains resolve publicly—without port scanning.
Hygiene signals
Verbose server banners and risky defaults can raise your attack surface and erode trust.
Not a vulnerability scan
Scorifya checks public configuration signals; it does not attempt exploitation, port scans, or authenticated crawling.
If you're iterating on config or deploying changes, you'll likely run multiple checks as you tighten things up. When you're ready, Scorifya Pro removes scan limits and unlocks JSON/CSV/PDF exports.