Reporting checker
Read a site's reporting headers, resolve every endpoint, and see which policies actually deliver reports and which are silently dropped.
Last update:
The reporting checker fetches a live page, reads its reporting headers, and shows where each browser policy sends its violations. It names the endpoints the response declares, marks the ones nothing points at, and lists every policy that is present but reports nowhere.
Reporting fails quietly. A policy with a typo in its endpoint name still enforces, still blocks, and still sends nothing. This tool is how you find that out without waiting for reports that never arrive.
Check a site
- Open Tools > Reporting checker.
- Enter the address, for example
example.com. - Leave Follow redirects on unless you want the response at that exact URL.
- Select Check reporting.
Read the Reporting tab
The score and the findings work the same way as in the other scanners, described on the Tools overview. What is specific to this tool is the Reporting tab, which holds two tables.
Reporting endpoints
One row per endpoint the response declares.
| Column | Means |
|---|---|
| Endpoint | The name the endpoint is declared under, for example default |
| URL | Where reports for that name are sent |
| Status | Used if at least one policy points at it, Unused otherwise |
| Declared in | Which header declared it, reporting-endpoints or report-to |
An Unused endpoint is dead weight, and usually a sign that a policy names a different endpoint than the one you configured.
The Declared in column is where a legacy setup shows itself. Reporting-Endpoints is the current header. Report-To is the deprecated one, and it is still the only header Network Error Logging reads its endpoint from, so a site that uses NEL keeps both.
Reported features
One row per policy the response carries.
| Column | Means |
|---|---|
| Feature | The policy, for example Content-Security-Policy or CSP script-hash reporting |
| Present | Whether the response sends the policy at all |
| Reports to | The endpoint URL its violations resolve to, or empty if it reports nowhere |
| Mode | Enforced if the policy blocks, Report-only if it only reports |
The checker covers Content-Security-Policy, CSP script-hash reporting, Cross-Origin-Opener-Policy, Cross-Origin-Embedder-Policy, Permissions-Policy, Document-Policy, Integrity-Policy, Connection-Allowlist, and Network Error Logging.
What the three states tell you
Reading the two tables together gives you one of three answers per policy:
- Present and pointing at a used endpoint. Reports are being delivered. Check the Mode column next, because a report-only policy reports without blocking.
- Present with an empty Reports to. The policy is active and its violations go nowhere. Add a
report-todirective naming an endpoint you declared. - Missing. The policy is not sent at all, so there is nothing to report.
A Report-only row across several policies is a common and deliberate state during a rollout. It becomes a finding because reported is not blocked, and a rollout left half-finished looks exactly the same from the outside.
Verify your own endpoint
When you point a site at CentralCSP, the same check runs behind Connect your site to confirm your headers reach us. Running the tool by hand is the way to re-check later, after a CDN change or a framework upgrade rewrites your headers.
Next steps
- Connect your site to start collecting reports
- Reporting API reference
- Header scanner, which includes the same Reporting tab
- Tools overview for sharing, exporting, and limits
Header scanner
Grade the whole response surface of a live URL. Every security header, the cookies it sets, and the reporting setup, scored and ranked by severity.
Overview
Invite people to the workspace, bundle them into groups, and grant website access. Two role systems, and where each one is managed.