Tools
Reporting API checker
Enter a URL and see where its browser reports actually go: Reporting-Endpoints, Report-To, the CSP report-uri fallback and NEL, feature by feature.
Check a URL
Inspect a site reporting setup: endpoints, feature reporting, and policies.
Sample result
What a check looks like
Which endpoints are declared, which features actually send reports to them, and what to fix first. A red None means the browser is generating reports and silently dropping every one.
Endpoints
Reporting endpoints declared by the site, and whether they are used.
| Endpoint | URL | Status | Declared in |
|---|---|---|---|
| csp-endpoint | Used | reporting-endpoints | |
| default | Used | reporting-endpoints | |
| legacy-analytics | Unused | report-to |
Features
Reporting status for each security feature and where its reports are sent.
Findings & recommendations
Issues and quality recommendations for the reporting setup.
Guide
Understanding browser reporting
The Reporting API is the browser mechanism that collects policy violations, network errors, deprecations and crashes and delivers them out of band to an endpoint you declare in a response header. Browsers will tell you when your Content Security Policy blocks something, when a fetch fails, or when a page uses a deprecated API. But they only tell you if your headers say where to send the report, and most sites never do.
What the checker looks at
It answers three questions about any URL: where did you tell browsers to send reports, which security features are actually wired to those endpoints, and which reports are being generated and thrown away. It reads only your response headers, because that is all a browser reads too: no agent, no JavaScript, nothing to install.
Reporting-Endpoints or Report-To?
Two headers can do the job, and one of them is living on borrowed time. Reporting-Endpoints is the current standard: one line of name-to-URL pairs. Report-To is its deprecated predecessor, and the only reason it refuses to die is Network Error Logging, which still requires it. If you are adding reporting today, declare your endpoints in Reporting-Endpoints. Both are covered in depth in the Reporting-Endpoints guide and the Report-To guide.
Reporting-Endpoints: default="https://<Endpoint-ID>.report.centralcsp.com", csp-endpoint="https://<Endpoint-ID>.report.centralcsp.com"
Report-To: {"group":"default","max_age":86400,"endpoints":[{"url":"https://<Endpoint-ID>.report.centralcsp.com"}]}Reporting-Endpoints, Report-To, report-to, report-uri
Four names, two headers and two CSP directives. This is the table people actually come looking for.
| Name | What it is | Status | When you still need it |
|---|---|---|---|
Reporting-Endpoints | Response header naming endpoints as name-to-URL pairs | Current | Always, for anything you set up today |
Report-To | Response header declaring endpoint groups as JSON | Deprecated, but required for NEL | Only if you collect Network Error Logging |
report-to | CSP directive pointing at an endpoint name declared in a header | Current | Always, to route CSP violations to an endpoint |
report-uri | CSP directive naming a URL directly, with no header needed | Deprecated | No longer needed: report-to and Reporting-Endpoints replace it |
Wiring CSP violation reports with report-to
The safest CSP rollout starts with reports, not rules. Ship the policy as Content-Security-Policy-Report-Only with a report-to directive pointing at an endpoint you declared in Reporting-Endpoints. Browsers then tell you exactly what the policy would have broken, and you tighten it before a single visitor is affected. The deprecated report-uri directive is not worth adding to a new policy: report-to and Reporting-Endpoints cover CSP violation reporting on their own. For the details, see the Content-Security-Policy overview and the CSP violation report guide.
Reporting-Endpoints: csp-endpoint="https://<Endpoint-ID>.report.centralcsp.com"
Content-Security-Policy-Report-Only: default-src 'self'; report-to csp-endpointNEL, the exception that still needs Report-To
Some failures never reach your server at all: DNS that does not resolve, TLS that does not complete, connections that die halfway. Network Error Logging is how browsers report those, and because the failed visit delivers no headers, the browser has to remember your config from an earlier successful one. That is why NEL still needs the legacy Report-To header, and why Reporting-Endpoints cannot replace it. Chromium-only. Full syntax in the Network Error Logging guide.
Report-To: {"group":"network-errors","max_age":2592000,"endpoints":[{"url":"https://<Endpoint-ID>.report.centralcsp.com"}]}
NEL: {"report_to":"network-errors","max_age":2592000}When reports do not arrive
Six causes cover nearly every silent endpoint.
- A page served over http://. The Reporting API only runs in a secure context, so a page that is not served over HTTPS generates no reports at all, whatever its headers say.
- An endpoint name nothing declares. A report-to directive points at an endpoint that no Reporting-Endpoints or Report-To header sets up, so the browser generates the report and drops it.
- An http:// endpoint. Browsers ignore it, with no error and no console warning.
- The wrong content type. The endpoint has to accept POST with application/reports+json, or application/csp-report for the legacy report-uri format.
- A response other than 2xx. Anything else and the browser treats the delivery as failed.
- The batching delay. The one most often mistaken for a fault. Browsers queue reports and send them a little after the page load that produced them, so an endpoint that looks dead thirty seconds after a test may simply not have been given time.
If you want to see the reports before any endpoint is wired at all, a page can read its own with ReportingObserver in JavaScript, which is a useful way to confirm the browser is generating what you expect.
How to read your results
The results are meant to be simple: they show you how your reporting is configured and flag anything that would break it. Referenced an endpoint that no header declares? Flagged. Declared an endpoint nothing sends to? Flagged. A policy that reports nowhere? Flagged too, with the fix right next to it. Fix what is flagged, re-run the check, and your reports keep arriving.
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
CSP evaluator
Paste a policy that is not deployed yet and get the same scoring and findings as a live scan, no URL required.
- Audit before you ship
- Same scoring engine
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
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
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
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
FAQ
Frequently asked questions
Endpoints, headers and missing reports, answered.
Endpoint checked. Now collect something with it.
CentralCSP gives you a managed reporting endpoint that accepts every generation: report-uri, Report-To and Reporting-Endpoints on the same URL. Reports arrive deduped, grouped and alerted in Slack or Teams. Add one header, no code changes.
