---
title: "Free CSP evaluator & validator - grade your policy"
description: "Paste a Content-Security-Policy and get a 0-100 grade: every directive checked, unsafe-inline, wildcards and JSONP bypasses flagged, fixes ranked by severity."
url: "https://centralcsp.com/en/tools/csp-evaluator/"
lang: "en"
---
Tools
# CSP evaluator
Paste a Content-Security-Policy and get a graded evaluation: weaknesses flagged directive by directive, with prioritized fixes.
### Evaluate a policy
Paste a Content-Security-Policy and get a graded evaluation: every directive checked, weaknesses flagged, prioritized fixes.
Evaluate policy
Paste the policy value, with or without the header name.
Is the policy already live on a site? [Scan the URL with the CSP scanner](https://centralcsp.com/en/tools/csp-scanner/)
Sample result
## See a graded policy before you paste yours
The kind of policy most sites still ship, graded and flagged directive by directive. Paste yours above to get the same verdict.
43 / 100
Critical CSP gaps
Overall CSP score
### Next actions
Replace 'unsafe-inline' in script-src with a nonce or hash
Stop allowlisting hosts with known JSONP endpoints
Replace the wildcard host with an exact hostname or a nonce
Add object-src 'none' and base-uri 'none'
Security
How well the site resists client-side attacks.
31 /100
The configuration has significant security gaps.
Quality
Hygiene only: typos, duplicates, dated values.
78 /100
A few things to tidy up: dated values, duplicated directives, options that no longer match current practice. None of them weakens the site, they just make it harder to maintain.
* * *
Flagged values are tinted by severity. Select one to see what is wrong, the impact, and the fix to apply.
content-security-policy[](https://centralcsp.com/en/docs/web-security/policies/content-security-policy)
default-src
'self'
script-src
'self' 'unsafe-inline' \*.example-cdn.com https://www.google-analytics.com
style-src
'self' 'unsafe-inline'
img-src
\*
* * *
### Findings & recommendations
Issues and quality recommendations for this Content-Security-Policy.
###
'unsafe-inline' allows any injected script to run The script-src directive allows inline scripts. An attacker who can inject HTML into the page can execute arbitrary JavaScript, which is the exact attack a CSP exists to stop.
Critical Security
Critical Security
Recommendation
Replace 'unsafe-inline' with a nonce or a hash for each inline script you actually ship. Browsers that support CSP Level 2 or 3 will then ignore a leftover 'unsafe-inline' fallback.
Impact
Any successful HTML injection becomes full cross-site scripting: session theft, payment form skimming, account takeover.
###
An allowlisted host exposes a JSONP endpoint that bypasses the policy www.google-analytics.com serves a JSONP endpoint. Because the whole host is trusted, an attacker can point a script tag at that endpoint with a callback of their choice and execute code with the policy enforced.
High Security
High Security
Recommendation
Load the analytics snippet with a nonce or hash plus 'strict-dynamic' instead of allowlisting the host, so trust attaches to the script you ship rather than to everything the host serves.
Impact
The policy reads as strict but is bypassable in practice: a known public technique turns the trusted host into an execution route.
Example
```
```
###
A wildcard host trusts every file on every subdomain \*.example-cdn.com allows scripts from any subdomain of the CDN. You are not trusting your bundle, you are trusting every customer upload and every forgotten bucket under that wildcard.
High Security
High Security
Recommendation
Pin the exact hostname you load from, or better, move script-src to a nonce or hash plus 'strict-dynamic' and drop the host list entirely.
Impact
Any attacker-controlled file anywhere under the wildcard executes as if it were your own code.
###
No object-src or base-uri fallback The policy sets neither object-src nor base-uri. Plugins fall back to default-src, and a missing base-uri lets an injected tag redirect every relative script URL on the page.
Medium Security
Medium Security
Recommendation
Add object-src 'none' and base-uri 'none' unless you have a documented reason to allow them.
Impact
Two well-known escape hatches stay open even after script-src is fixed.
###
img-src \* allows images from any origin A wildcard image source is rarely exploitable on its own, but it makes the policy noisy to review and can leak visitor data to arbitrary origins through image requests.
Low Quality
Low Quality
Recommendation
List the image origins you actually use, or use 'self' plus your CDN.
Impact
A maintainability and privacy smell rather than a direct execution risk; it lowers the quality score, not the security score.
Guide
## Understanding your CSP evaluation
A Content-Security-Policy is only as strong as its weakest directive. The evaluator reads the policy the way an attacker would: it looks for the keyword, the wildcard, or the allowlisted host that turns your header into a bypass.
### How this compares to Google's CSP Evaluator
[Google's CSP Evaluator](https://csp-evaluator.withgoogle.com) and ours flag the same core weaknesses. What differs is what you get back, and what happens after the policy ships.
Our CSP evaluator compared with Google's CSP Evaluator
| Capability | CentralCSP | Google's CSP Evaluator |
| --- | --- | --- |
| Per-finding severity | Yes | Yes |
| Known allowlist and JSONP bypass checks | Yes | Yes |
| Overall 0-100 grade | Yes | No |
| Separate security and quality scores | Yes | No |
| Findings ordered by severity, each with a next action | Yes | Flags the weakness |
| Parsed directive view pinning each finding to its value | Yes | Per-directive listing |
| Accepts a Report-Only policy value | Yes | Not distinguished |
| Violation reporting once the policy is deployed | Yes, through CentralCSP | No |
### What the evaluator checks
The policy is parsed directive by directive and every source value is checked for what an attacker could use: unsafe keywords, overly broad sources, missing fallback directives, and allowlisted hosts that can be abused to run code the policy was supposed to block. Each class of weakness is explained in the [script-src directive reference](https://centralcsp.com/en/docs/web-security/policies/content-security-policy/directives/script-src).
### How to read the scores
The verdict is built to be acted on: every weakness is pinned to the directive that caused it, with the fix right next to it. A dangerous keyword? Flagged. A source broad enough to be abused? Flagged too. Chase the security score first, a tidy policy can still be wide open, and clear the next actions in order: they are already sorted by what an attacker would use first.
### What a good CSP score looks like
Two axes, one to chase. The security score measures how well the policy resists real attacks; the quality score measures how cleanly it is written. A policy can be immaculately authored and still leave the door open, so when the two disagree, the security score is the one that matters.
What each score band means
| Score | What it means |
| --- | --- |
| 80 and above | A solid CSP setup. Worth keeping under monitoring so it does not drift. |
| 50 to 79 | Needs attention. The policy exists but something in it undoes a good part of the protection. |
| Below 50 | Critical gaps. Treat the top findings as the work, not as a backlog. |
### Three findings you will almost certainly see
'unsafe-inline' in script-src is the first. It allows any injected script to run, which is the exact thing the directive exists to stop. The fix is a nonce or a hash for the inline code you actually need.
A wildcard or a long host allowlist is the second. A wildcard host trusts every file on every subdomain, and a long allowlist is only as strong as its weakest entry: one host serving a JSONP endpoint is enough to bypass the policy. The fix is to shorten the list, or move to a nonce with strict-dynamic so the list stops carrying the weight.
A missing object-src or base-uri is the third. Neither falls back to default-src in a way that protects you, so both should be set to 'none' unless you have a specific reason not to.
### Check a policy before it ships
Because the evaluator works on the policy text alone, nothing has to be live. Paste the value from your nginx config, your middleware, or a teammate's pull request and review it before it reaches production. It also reads a Content-Security-Policy-Report-Only value, so you can grade the policy you are trialing before you enforce it.
A clean evaluation is step one, not proof. Deploy the policy in report-only mode first and watch what real browsers report; the policy that looks strict on paper is often the one that blocks your own checkout script. When the site is live, [scan the URL with the CSP scanner](https://centralcsp.com/en/tools/csp-scanner/) to confirm the header your server actually sends matches what you evaluated.
### Why an allowlist policy still gets bypassed by JSONP
Most policies in the wild are allowlists, and that is why they fail: you are not trusting hosts, you are trusting every file on them, and a single abusable endpoint on an allowlisted CDN runs attacker code with the policy enforced. [How JSONP endpoints bypass your CSP](https://centralcsp.com/en/blog/jsonp-csp-bypass) walks through the bypass step by step.
The fix is a strict CSP: replace the host list with a nonce or hash plus 'strict-dynamic', so trust attaches to the scripts you tagged rather than to whole origins, and close the fallback gaps with object-src 'none' and base-uri 'none'. How nonces and hashes work is covered in the [CSP hashes and nonces guide](https://centralcsp.com/en/docs/web-security/policies/content-security-policy/values/csp-hashes-nonce). The full syntax is in the [script-src directive reference](https://centralcsp.com/en/docs/web-security/policies/content-security-policy/directives/script-src).
### When a security rating flags your CSP
Rating platforms like [SecurityScorecard](https://securityscorecard.com) and [Bitsight](https://www.bitsight.com) score your CSP from the outside, and a finding like "Content Security Policy Contains Broad Directives" often arrives via a customer or an insurer. Paste the exact policy from the finding here to see what their scanner saw and which directive triggered it.
Fix the flagged directive, evaluate the corrected policy until it comes back clean, then deploy it and use the platform's own resolve or rescan flow. A decorative wide-open policy no longer helps: rating scanners grade permissive policies as failures, so the finding only closes with a policy that is genuinely tighter.
Keep reading
- [Content-Security-Policy overview](https://centralcsp.com/en/docs/web-security/policies/content-security-policy)
- [The script-src directive](https://centralcsp.com/en/docs/web-security/policies/content-security-policy/directives/script-src)
- [CSP hashes and nonces](https://centralcsp.com/en/docs/web-security/policies/content-security-policy/values/csp-hashes-nonce)
- [CSP violation reports](https://centralcsp.com/en/docs/web-security/reporting-api/reports/csp-violation)
- [How JSONP endpoints bypass a CSP](https://centralcsp.com/en/blog/jsonp-csp-bypass)
- [strict-dynamic explained](https://centralcsp.com/en/blog/strict-dynamic-csp)
- [CSP keyword reference](https://centralcsp.com/en/docs/web-security/policies/content-security-policy/values/csp-keywords)
- [A strict CSP starter template](https://centralcsp.com/en/blog/csp-starter-template)
More free tools
## Keep auditing with the other free tools
Every tool is free, runs without an account, and scores with the same severity scale.
### CSP scanner
Fetch a URL's live Content-Security-Policy and score it against known bypasses, wildcard sources and missing directives.
- Directive-level findings
- Shareable results link
[Run the CSP scanner](https://centralcsp.com/en/tools/csp-scanner/)
### Security headers scanner
Grade every security header a URL sends, from HSTS to Permissions-Policy, with each finding explained and prioritized.
- Every header, one grade
- Fix list ordered by impact
[Scan your security headers](https://centralcsp.com/en/tools/security-headers/)
### Reporting API checker
Check that violation reporting actually works: endpoints, Reporting-Endpoints and Report-To, and which security features really report.
- Endpoint and feature mapping
- Silent drops flagged
[Check your Reporting API setup](https://centralcsp.com/en/tools/reporting-api/)
### SRI hash generator
Turn a CDN script or stylesheet URL into its Subresource Integrity hash, with a ready-to-paste tag and a CORS check.
- SHA-256, 384 and 512
- CORS verified for you
[Generate an SRI hash](https://centralcsp.com/en/tools/sri-hash/)
### CSP hash generator
Turn an inline script or style into the hash that lets it run under a strict policy, right in your browser.
- Runs entirely client-side
- SHA-256, 384 and 512
[Generate a CSP hash](https://centralcsp.com/en/tools/csp-hash/)
### Website compare
See where your score stands: your site beside the dataset average and the year's best-configured sites, control by control.
- Published, auditable references
- Radar view per category
[Compare your site to the best](https://centralcsp.com/en/tools/compare/)
FAQ
## Frequently asked questions
Scoring, bypasses and pre-deploy checks, answered.
### Is this CSP evaluator free?
Yes. Paste a policy and evaluate it as often as you need: no account, no email, no install. The policy is analyzed by the CentralCSP API and the verdict comes back in seconds; an invisible anti-bot check runs in the background instead of a captcha puzzle. Only the policy text you paste is sent. Nothing else about your site is touched: there is no crawl and no request to your server.
### What is the difference between the CSP evaluator and the CSP scanner?
The evaluator reads a policy string you paste, so it works before anything is deployed: on a config file, a pull request, or a header you copied from a guide. The scanner takes a URL, fetches the page and reads the Content-Security-Policy the server actually sends, including a Report-Only one, which is how you check what is live rather than what you meant to ship. Both use the same severity scale and the same score bands, so a verdict from one is directly comparable to the other.
### How is this different from Google's CSP Evaluator?
Google's CSP Evaluator flags weaknesses in a pasted policy and it does that well. This tool flags the same core issues and adds a 0 to 100 grade, separate security and quality scores, next actions ordered by severity, and a parsed view that pins each finding to the directive that caused it. It is also the front door to monitoring: once the policy ships, CentralCSP can collect violation reports from real browsers instead of leaving you with a one-off paste.
### What does a good Content-Security-Policy look like?
A strict policy trusts specific scripts, not whole hosts: script-src with a nonce or hash plus 'strict-dynamic', object-src 'none', and base-uri 'none'. Long host allowlists, 'unsafe-inline', and wildcards are what evaluators flag, because each one is a documented bypass route. If your policy is a list of CDNs, expect a low security score even if every host is one you use.
### Why is 'unsafe-inline' flagged as a serious problem?
'unsafe-inline' allows every inline script on the page to run, including the one an attacker injects, which defeats the main point of a CSP. Replace it with a nonce or a hash for the inline code you actually ship. One nuance: in a policy that already has a nonce or hash, browsers that support CSP Level 2 or 3 ignore 'unsafe-inline', so keeping it purely as a fallback for old browsers is accepted practice and scored accordingly.
### Can I evaluate a policy that is not deployed yet?
Yes, that is the point of pasting instead of scanning. The evaluator only reads the policy text, so a value from a config file, a pull request, or a report-only trial works the same as a live header. When the policy is deployed, use the CSP scanner to confirm the header your server actually sends, on every response, matches what you evaluated.
### Does a high score mean my site is safe from XSS?
No. The score grades the policy text: it cannot see whether the header ships on every page, whether it is enforced or report-only, or what breaks in real browsers once it is live. A strict CSP is a strong XSS mitigation, not a replacement for fixing injection bugs. Treat a high score as a prerequisite, then verify deployment with a scan and watch violation reports in production.
## Your policy will change. Re-check it automatically.
The evaluator grades a snapshot. CentralCSP watches the policy your site actually serves and collects violation reports from your visitors' browsers, so a new script, a weakened directive, or a broken page shows up as an alert instead of an incident. Add one header, no code changes.
[Start with CentralCSP](https://app.centralcsp.com) [Build a CSP from your real traffic](https://centralcsp.com/en/platform/csp-builder/)
---
Available in: [en](https://centralcsp.com/en/tools/csp-evaluator/), [fr](https://centralcsp.com/fr/tools/csp-evaluator/)