CSP Evaluator
Is my Content Security Policy strong enough?
A Content Security Policy only stops cross-site scripting if it's written tightly: one 'unsafe-inline' or a wildcard on a shared host and an injected script runs anyway. Paste your policy or enter a URL, and this CSP evaluator shows what a browser will actually allow and what to change.
Paste the policy, the full header line, or a meta tag. It's checked in your browser as you type.
What this CSP evaluator checks
Inline scripts and eval
'unsafe-inline' and 'unsafe-eval' in script-src, and whether a nonce or hash already cancels 'unsafe-inline' in modern browsers.
Wildcards and schemes
*, https:, data:, and blob: sources that let scripts load from anywhere, including a domain an attacker owns.
Bypassable hosts
Open CDNs like jsDelivr and unpkg, AngularJS and JSONP hosts, and wildcards on shared platforms like *.vercel.app, where anyone can publish a script.
Missing directives
object-src, base-uri, frame-ancestors, and form-action, including the ones that don't fall back to default-src.
Syntax mistakes
Keywords without quotes, misspelled directives, duplicates the browser ignores, and 'none' mixed in with other sources.
Nonces, strict-dynamic, and report-only
Short nonces, 'strict-dynamic' switching off host allowlists, directives a meta tag can't use, and report-only policies that block nothing.
Read more →How the CSP Evaluator works
- Step 1
Paste a policy or enter a URL
Paste the policy, a header line, or a meta tag. Or enter a URL and we'll read its Content-Security-Policy header and meta tag.
- Step 2
It's read the way browsers read it
Fallbacks to default-src, the first copy of a repeated directive winning, nonces overriding 'unsafe-inline', and 'strict-dynamic' overriding host sources are all applied before anything is flagged.
- Step 3
Fix it and check again
Each finding says what to change. Rebuild the policy with the CSP Generator, deploy it, and run the URL check to confirm what browsers receive.
Frequently asked questions
What does a CSP evaluator do?
It reads a Content Security Policy the way a browser does and tells you whether it would actually stop an injected script. Having a CSP header isn't the same as being protected: policies with 'unsafe-inline', a scheme like https:, or an allowlisted CDN that hosts anyone's files let injected scripts run anyway. An evaluator finds those gaps, along with missing directives and syntax mistakes that quietly switch off part of the policy.
Why is 'unsafe-inline' bad in script-src?
Cross-site scripting usually works by getting a script tag or an inline handler like onerror into your page. 'unsafe-inline' tells the browser to run exactly that kind of code, so the policy no longer blocks the most common attack. The fix is to move inline scripts into files, or give the legitimate ones a nonce or hash. Once a nonce or hash is present, modern browsers ignore 'unsafe-inline', which is why some strong policies still include it for old browsers.
What makes a strong Content Security Policy?
The strongest widely used pattern is nonce-based: script-src with a fresh random nonce and 'strict-dynamic', plus object-src 'none' and base-uri 'none' or 'self'. Because the nonce changes on every response, injected scripts without it don't run, and 'strict-dynamic' lets your approved scripts load their own dependencies. Allowlists of hosts are weaker, because many popular hosts serve files that anyone can publish.
Is it free? Do I need to sign in?
Yes. It's free, with no account and no sign-in. There's a rate limit to stop the tool being abused, and that's the only limit. Ubserve makes money from its paid security report, not from this page. The full scan it pairs with is free to run too: you get a grade, an issue count, and up to two findings in full before anything is asked of you.
Does my policy get sent to Ubserve?
A pasted policy doesn't. It's evaluated as you type, in your browser. When you check a URL, our server loads that page once to read its Content-Security-Policy header and meta tag, sends back only the policy, and discards the rest of the page. The evaluation itself then runs in your browser.
Can I set a CSP in a meta tag?
Yes, with a meta tag whose http-equiv is Content-Security-Policy, which helps on static hosts where you can't set headers. Three directives are ignored there: frame-ancestors, report-uri, and sandbox. The tag also only covers what comes after it in the page, so put it at the top of the head. A response header is better whenever your host lets you set one.
What founders say
5.0 out of 5 - Ubserve, from 3 reviews
“Helped me find a critical database issue that would've done real damage. I recommend it for every founder.”
“Caught a critical CSP issue on my frontend within minutes. Don't ship without a scan.”
“The free scan took under 60 seconds to find real issues in my project.”
Other free tools
See all tools →Security Headers Checker
Reads the response headers your site actually sends and grades what is missing, weak, or leaking your stack.
Open tool →CSP Generator
Builds a Content Security Policy and the rest of your security headers as copy-paste config for Next.js, Vercel, Netlify, or Cloudflare Pages.
Open tool →CORS Tester
Test a URL's CORS headers and preflight, see exactly why the browser blocks your request, and whether other websites can read your API.
Open tool →Keep reading
- Vulnerabilities we catchWhat a full scan finds beyond headers.
- Pre-deploy security checklist for vibe-coded appsThe last pass before you ship.
- How to secure a vibe-coded app before productionOrder of operations for a launch week.
- Why vibe-coded apps keep getting hackedWhere missing headers show up in real incidents.
- Vibe coding security risksThe risks that come with shipping AI-written code.
Check what your live app serves
Anything you check here only covers what you hand it. What an attacker sees is what your deployed app serves, so paste your URL and check that too.