# Overview (/en/docs/platform/tools)



Tools grade a configuration on demand and keep the result. Three of them fetch a live URL and score what the response returns. The fourth scores a Content Security Policy (CSP) value you paste in, before it reaches a server.

This is the on-demand half of CentralCSP. [Reports](/en/docs/platform/monitoring) is the continuous half, built from what real browsers send about your pages. A scan tells you what one page serves right now, from one address, without touching your site's configuration.

Every workspace member can use all four tools. No plan unlocks them and none is disabled.

## The four tools [#the-four-tools]

| Tool                                                               | Answers                                                          | Fetches a URL |
| ------------------------------------------------------------------ | ---------------------------------------------------------------- | ------------- |
| [CSP scanner](/en/docs/platform/tools/csp-scanner)                 | What the policy a live page serves allows, and where it is weak  | Yes           |
| [Header scanner](/en/docs/platform/tools/security-header-scanner)  | How every security header and cookie in the response holds up    | Yes           |
| [Reporting checker](/en/docs/platform/tools/reporting-api-checker) | Where the site sends browser reports, and which ones are dropped | Yes           |
| [CSP evaluator](/en/docs/platform/tools/csp-evaluator)             | The same policy review, for a header value you have not deployed | No            |

Pick the scanner by the question. The CSP scanner scopes its score to the policy, so a site with a good policy and no other headers still scores well. The header scanner grades the whole response, so the same site scores lower. The reporting checker scopes its score to the reporting setup. **A score only compares with another score from the same tool.**

## Run a scan [#run-a-scan]

The three scanners share one form and one result page.

### 1. Enter the address [#1-enter-the-address]

Type a domain like `example.com` or a full URL. A missing scheme becomes `https://`.

**Follow redirects** is on by default, so the scan grades the page the address lands on. Turn it off to grade the response at the exact URL you typed, which is what you want when you are checking a redirect itself.

### 2. Wait for the result [#2-wait-for-the-result]

The scan opens its own result page and refreshes until it settles. Most finish in a few seconds, and the scanner gives up after about a minute.

### 3. Read the scores [#3-read-the-scores]

The result opens on three scores out of 100:

| Score        | Means                                                              |
| ------------ | ------------------------------------------------------------------ |
| **Overall**  | The tool's headline grade, weighted over the checks that tool runs |
| **Security** | How well the configuration resists client-side attacks             |
| **Quality**  | How cleanly the headers and policies are defined                   |

A site can score 96 on quality and 40 on security at the same time. That combination means the headers it does send are written correctly, and the ones that would stop an attack are missing.

**Next actions** lists up to five concrete changes, most severe first. Start there.

### 4. Work through the findings [#4-work-through-the-findings]

The result page has three tabs, plus a fourth on two of the tools:

* **Findings.** Every issue and quality recommendation, most severe first, tagged `Critical`, `High`, `Medium`, `Low`, or `Info` and classed as Security or Quality. Filter to one class with the control on the right. Expand a finding for its recommendation, its impact, an example fix, the exact headers, directives, and values it flagged, and links to the reference docs.
* **Analyzed headers.** The headers the scanner graded, parsed directive by directive. A value that caused a finding is highlighted in its severity color, so you can see which token in a long policy is the problem.
* **Raw headers.** Every response header exactly as the scanner received it, graded or not. `Set-Cookie` values are hidden here because a result is shareable. The [header scanner](/en/docs/platform/tools/security-header-scanner) shows the cookie attributes in its own table instead.
* **Reporting.** Where the response sends browser reports, and which report types reach an endpoint. Only the [header scanner](/en/docs/platform/tools/security-header-scanner) and the [reporting checker](/en/docs/platform/tools/reporting-api-checker) have this tab.

## What the result header tells you [#what-the-result-header-tells-you]

The result header names the URL the scanner ended up analyzing, when it ran, and how the server answered:

* The HTTP status it returned.
* The content type, shortened to a label such as `HTML` or `JSON`.
* A redirect count, if the scan followed any. Hover it for the full hop chain with each status.
* The IP address the hostname resolved to.

Check these first when a result surprises you. A 403 with a redirect chain usually means a bot filter answered instead of your site.

## Share, export, rescan [#share-export-rescan]

Three actions sit in the header of every scan result.

**Share** copies a public link to the result on `centralcsp.com`. The link needs no account, so anyone who has it can read the finding list and the headers of the page you scanned. Treat a result as shareable rather than confidential.

**Export** writes the result to a file. CSV gives one row per finding with its severity, class, code, title, recommendation, and impact. PDF renders the full report for the same view the tool shows.

**Rescan** runs the same target again with the same redirect setting, and opens the new result. The old one stays in your history, so the two are comparable side by side.

## Your scan history [#your-scan-history]

Each scanner keeps its own history on its own page, newest first, with the target, the overall score, a count per severity, the status, and when it ran. Select a row to reopen the full result. The search box filters by target.

**The history is yours, not the workspace's.** It never lists another member's scans, and another member never sees yours. Anyone holding a result link can still read that result.

The [CSP evaluator](/en/docs/platform/tools/csp-evaluator) has no history. It stores nothing.

## When a scan finds nothing to grade [#when-a-scan-finds-nothing-to-grade]

A scan that finishes without a score is not the same as a failed one. The result says which case you hit:

| Message                                      | Cause                                                     |
| -------------------------------------------- | --------------------------------------------------------- |
| The host could not be resolved               | A typo, or a hostname that does not exist publicly        |
| Nothing answered on the web ports            | The address resolves but serves no HTTP or HTTPS          |
| A private or internal network is not scanned | The address resolves to a private range                   |
| The site did not answer in time              | A timeout                                                 |
| The site redirected too many times           | A redirect loop                                           |
| Bot protection blocked the scan              | A challenge page answered, and the scanner graded nothing |
| The site answered with an error status       | A 4xx or 5xx response                                     |

The scanner runs from the public internet. A site that is only reachable inside your network, on a private IP range, or behind a VPN cannot be scanned at all, and no allowlist changes that. Expose a staging hostname publicly, or use the [CSP evaluator](/en/docs/platform/tools/csp-evaluator) on the policy value instead.

## If a firewall blocks the scanner [#if-a-firewall-blocks-the-scanner]

Scans arrive from a fixed set of addresses. A web application firewall (WAF), a rate limiter, or a bot filter that challenges them turns into a `challenge` outcome, a 403, or a result that reports no headers on a site you know sends them.

Allowlist the scanner for inbound HTTP and HTTPS before you report a scan as wrong. The current addresses and the symptoms of a block are on [Scanner IP address](/en/docs/platform/security/scanner-ip). The API returns the same list from `GET /v1/workspaces/{workspaceId}/scans/ips`, so a rule set you maintain automatically can read it rather than being edited by hand.

Allowlisting affects inbound scan traffic only. Browser reports arrive from your visitors' own addresses and are unaffected either way.

## Limits [#limits]

Scans are capped per person, so one member cannot drain a colleague's budget, and being in two workspaces does not hand out two budgets.

| Action                                            | Limit                     |
| ------------------------------------------------- | ------------------------- |
| Scans that produce a result                       | 100 per day               |
| Scan attempts, including ones the scanner refuses | 300 per day               |
| Scans started                                     | 10 per minute             |
| PDF exports                                       | 10 per minute, 50 per day |
| Policy evaluations                                | 30 per minute             |

## Next steps [#next-steps]

* [CSP scanner](/en/docs/platform/tools/csp-scanner)
* [Header scanner](/en/docs/platform/tools/security-header-scanner)
* [Reporting checker](/en/docs/platform/tools/reporting-api-checker)
* [CSP evaluator](/en/docs/platform/tools/csp-evaluator)
* [Connect your site](/en/docs/platform/websites/connect-your-site) to collect reports continuously
* [Content Security Policy reference](/en/docs/web-security/policies/content-security-policy) and [Security headers reference](/en/docs/web-security/security-headers) for what each check is grading