# CSP scanner (/en/docs/platform/tools/csp-scanner)



The CSP scanner fetches a live page and grades the [Content Security Policy](/en/docs/web-security/policies/content-security-policy) it serves. You get a score out of 100, a ranked list of what to fix, and the policy parsed directive by directive with the weak values highlighted.

Use it to check what a site actually serves, which is not always what the configuration says it serves. A content delivery network (CDN), a reverse proxy, or a framework can add, strip, or rewrite the header on the way out.

## When to use the CSP scanner [#when-to-use-the-csp-scanner]

* The policy is **already deployed** and you want it graded. Use this page.
* The policy is **a draft** you have not shipped. Use the [CSP evaluator](/en/docs/platform/tools/csp-evaluator), which grades a value you paste in and fetches nothing.
* You want the **whole response** graded, not just the policy. Use the [header scanner](/en/docs/platform/tools/security-header-scanner).

## Scan a policy [#scan-a-policy]

1. Open **Tools** > **CSP scanner**.
2. Enter the address, for example `example.com`. A missing scheme becomes `https://`.
3. Leave **Follow redirects** on unless you want the response at that exact URL rather than where it lands.
4. Select **Scan policy**.

The result page opens while the scan runs and fills in when it settles.

## What the score covers [#what-the-score-covers]

The overall score is labeled **Overall CSP score**, and it is weighted over the policy checks only. A site that serves a strong CSP and no other security header scores well here and lower on the [header scanner](/en/docs/platform/tools/security-header-scanner).

Alongside it sit **Security**, which is how well the policy resists client-side attacks, and **Quality**, which is how cleanly it is written. A high quality score with a low security score means the policy is correct but permissive.

## What it checks [#what-it-checks]

The findings cover the ways a policy fails to contain an attack, and the ways it is written untidily. Among them:

* **Injection containment.** Whether [`script-src`](/en/docs/web-security/policies/content-security-policy/directives/script-src) is strict, meaning a nonce or hash plus `'strict-dynamic'`, or `'none'` or `'self'` alone. A permissive `script-src`, an open [`base-uri`](/en/docs/web-security/policies/content-security-policy/directives/base-uri), [`object-src`](/en/docs/web-security/policies/content-security-policy/directives/object-src), or `style-src` all re-open a policy that is otherwise strict.
* **Exfiltration containment.** Whether [`connect-src`](/en/docs/web-security/policies/content-security-policy/directives/connect-src), `img-src`, and [`form-action`](/en/docs/web-security/policies/content-security-policy/directives/form-action) restrict where the page can send data. `connect-src *`, a bare scheme such as `https:`, or an absent directive with no `default-src` to inherit from all flag as an exfiltration channel.
* **Third-party script integrity.** Whether the policy allowlists third-party origins without requiring [Subresource Integrity](/en/docs/web-security/other/subresource-integrity). That combination is what a compromised vendor script exploits.
* **Fallbacks.** A missing [`default-src`](/en/docs/web-security/policies/content-security-policy/directives/default-src), so directives with no explicit rule load from anywhere.
* **Reporting.** Whether the policy sets `report-to` or `report-uri` at all, and whether it carries a [`'report-sha256'`](/en/docs/web-security/policies/content-security-policy/values/report-sha-keyword) keyword. Without the keyword, browsers never report the hashes of the scripts they executed, which is what a [script inventory](/en/docs/platform/features/script-inventory) is built from.
* **Deprecated and legacy directives**, and [policies delivered in a `meta` tag](/en/docs/web-security/policies/content-security-policy/introduction/csp-headers), which cannot use `frame-ancestors`, `report-uri`, or `sandbox`.

A result also flags when the site sends no `Content-Security-Policy` at all. A page with no policy is exposed by default, so that case scores as a finding, not as a blank result.

## Read the parsed policy [#read-the-parsed-policy]

The **Analyzed headers** tab shows each policy header, its source, and its directives broken out one by one. Every value is a chip. A chip that caused a finding carries the finding's severity color and its icon, so a long policy shows you which token is the problem without reading the whole line.

`Content-Security-Policy` and `Content-Security-Policy-Report-Only` are graded separately, and a report-only policy that has no enforced counterpart is called out. Reported is not blocked.

**Raw headers** shows the untouched response, which is where you confirm that the header reached the browser in the form you expected.

## When nothing reports [#when-nothing-reports]

If the scanned policy sends its violations nowhere, the result shows a banner saying so, with a shortcut to add the site to CentralCSP. A policy with no endpoint blocks silently, so every break it causes goes unseen.

To start collecting, see [Connect your site](/en/docs/platform/websites/connect-your-site).

## Next steps [#next-steps]

* [CSP evaluator](/en/docs/platform/tools/csp-evaluator) to grade a policy before you deploy it
* [Header scanner](/en/docs/platform/tools/security-header-scanner) to grade the rest of the response
* [Content Security Policy reference](/en/docs/web-security/policies/content-security-policy)
* [Tools overview](/en/docs/platform/tools) for sharing, exporting, and limits