CentralCSP dashboard tools for CSP and security headers

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 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

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

The three scanners share one form and one result page.

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

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

The result opens on three scores out of 100:

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

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 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 and the reporting checker have this tab.

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

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

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 has no history. It stores nothing.

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:

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 on the policy value instead.

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. 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

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.

Next steps

• CSP scanner
• Header scanner
• Reporting checker
• CSP evaluator
• Connect your site to collect reports continuously
• Content Security Policy reference and Security headers reference for what each check is grading