--- title: "Reporting API checker - free Reporting-Endpoints test" description: "Free Reporting API checker: scan any URL's Reporting-Endpoints, Report-To, CSP report-uri and NEL, and find the reports browsers silently drop. No signup." url: "https://centralcsp.com/en/tools/reporting-api/" lang: "en" --- 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. Follow redirects Scan reporting setup Auditing more than the reporting setup? [Run the security headers scanner](https://centralcsp.com/en/tools/security-headers/) 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 | https://k4x2c9wq.report.centralcsp.com | Used | reporting-endpoints | | default | https://f8g1n3ap.report.centralcsp.com | Used | reporting-endpoints | | legacy-analytics | https://a1b7d2xe.report.centralcsp.com | Unused | report-to | * * * ### Features Reporting status for each security feature and where its reports are sent. | Feature | Present | Mode | Endpoint | Reporting URLs | | --- | --- | --- | --- | --- | | Content Security Policy[](https://centralcsp.com/en/docs/web-security/policies/content-security-policy) | Present | Enforced | csp-endpoint | https://k4x2c9wq.report.centralcsp.com | | Cross-Origin-Opener-Policy[](https://centralcsp.com/en/docs/web-security/policies/cross-origin-opener-policy) | Present | Report-Only | coop | None | | Permissions Policy[](https://centralcsp.com/en/docs/web-security/policies/permissions-policy) | Present | Enforced | default (fallback) | https://f8g1n3ap.report.centralcsp.com | | Network Error Logging[](https://centralcsp.com/en/docs/web-security/policies/network-error-logging) | Not present | | | | * * * ### Findings & recommendations Issues and quality recommendations for the reporting setup. ### COOP reports are silently dropped Cross-Origin-Opener-Policy-Report-Only names the endpoint coop, but no Reporting-Endpoints or Report-To header declares an endpoint with that name. High Security High Security Recommendation Add coop="https://.report.centralcsp.com" to the Reporting-Endpoints header, or change the report-to directive to point at an endpoint that is declared. Impact The browser generates a report for every COOP violation and discards it, so the policy looks wired while nothing ever arrives. ### Endpoint legacy-analytics is declared but never used The Report-To header declares the group legacy-analytics, but no feature on the page sends reports to it. Medium Quality Medium Quality Recommendation Remove the legacy-analytics group from the Report-To header, or point a feature at it if it is still needed. Impact Unused declarations make a reporting setup harder to audit and usually signal a configuration that drifted from what the site actually sends. 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](https://centralcsp.com/en/docs/web-security/reporting-api/headers/reporting-endpoints) and the [Report-To guide](https://centralcsp.com/en/docs/web-security/reporting-api/headers/report-to). ``` Reporting-Endpoints: default="https://.report.centralcsp.com", csp-endpoint="https://.report.centralcsp.com" Report-To: {"group":"default","max_age":86400,"endpoints":[{"url":"https://.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. The two reporting headers and the two CSP reporting directives compared | 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](https://centralcsp.com/en/docs/web-security/policies/content-security-policy) and the [CSP violation report guide](https://centralcsp.com/en/docs/web-security/reporting-api/reports/csp-violation). ``` Reporting-Endpoints: csp-endpoint="https://.report.centralcsp.com" Content-Security-Policy-Report-Only: default-src 'self'; report-to csp-endpoint ``` ### NEL, 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](https://centralcsp.com/en/docs/web-security/policies/network-error-logging). ``` Report-To: {"group":"network-errors","max_age":2592000,"endpoints":[{"url":"https://.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. Keep reading - [The Reporting-Endpoints header](https://centralcsp.com/en/docs/web-security/reporting-api/headers/reporting-endpoints) - [The Report-To header](https://centralcsp.com/en/docs/web-security/reporting-api/headers/report-to) - [Network Error Logging (NEL)](https://centralcsp.com/en/docs/web-security/policies/network-error-logging) - [CSP violation reports](https://centralcsp.com/en/docs/web-security/reporting-api/reports/csp-violation) - [Report-To vs Reporting-Endpoints, in depth](https://centralcsp.com/en/docs/web-security/reporting-api/concepts/report-to-vs-reporting-endpoints) - [The default reporting endpoint](https://centralcsp.com/en/docs/web-security/reporting-api/concepts/default-endpoint) - [The application/reports+json envelope](https://centralcsp.com/en/docs/web-security/reporting-api/concepts/report-delivery-format) - [How to set up the browser Reporting API](https://centralcsp.com/en/blog/how-to-set-up-the-reporting-api) 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 [Run the CSP scanner](https://centralcsp.com/en/tools/csp-scanner/) ### 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 [Evaluate a policy in the CSP evaluator](https://centralcsp.com/en/tools/csp-evaluator/) ### 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 [Scan your security headers](https://centralcsp.com/en/tools/security-headers/) ### 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 [Generate an SRI hash](https://centralcsp.com/en/tools/sri-hash/) ### 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 [Generate a CSP hash](https://centralcsp.com/en/tools/csp-hash/) ### 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 [Compare your site to the best](https://centralcsp.com/en/tools/compare/) FAQ ## Frequently asked questions Endpoints, headers and missing reports, answered. ### What is the Reporting-Endpoints header? Reporting-Endpoints is an HTTP response header that names the URLs a browser should send its reports to, as simple name-to-URL pairs: Reporting-Endpoints: csp-endpoint="https://.report.centralcsp.com". Features like CSP then reference a name with their report-to directive. It is the current standard of the W3C Reporting API and replaces the older Report-To header. ### Is the Report-To header deprecated? Yes. Report-To belongs to the first version of the Reporting API and has been replaced by Reporting-Endpoints, which uses a simpler syntax and no cached lifetime. There is one reason to keep it: Network Error Logging only works through a Report-To group, so a site that wants NEL reports still ships both headers. For everything else, declare your endpoints in Reporting-Endpoints. ### Which browsers support Reporting-Endpoints? Reporting-Endpoints and the report-to directive are the current standard and are what a new setup should ship. Coverage is not uniform across every browser, but the fallback is silence rather than breakage: a browser that does not understand the header simply sends nothing. Network Error Logging is the one Chromium-only piece, and the only reason to keep the legacy Report-To header alongside. ### Can I set Reporting-Endpoints in a meta tag? No. Reporting-Endpoints is a response header and there is no meta equivalent. A Content-Security-Policy delivered in a meta http-equiv tag cannot carry reporting directives either, so a site that can only set a policy in HTML cannot collect reports from it at all. That is one more reason reports go missing on platforms where you do not control the response headers. ### Do I still need report-uri in my CSP? No. A report-to directive pointing at an endpoint declared in Reporting-Endpoints is all a policy needs for CSP violation reports, and report-uri is deprecated. Adding it to a new policy buys you nothing and leaves a second destination to keep in sync. If an existing policy still carries one, you can drop it once this checker confirms your report-to endpoint is receiving reports. ### Why is my reporting endpoint not receiving reports? The most common cause is a dangling reference: a report-to directive names an endpoint that no Reporting-Endpoints or Report-To header declares, so the browser drops every report it generates. Also check that the endpoint accepts POST requests with the application/reports+json content type (application/csp-report for legacy report-uri), returns a 2xx, and is served over HTTPS. And be patient: browsers batch reports and send them a little after the triggering page load. This checker flags dangling references and unused endpoints directly. ### Which report types can a browser send? Through the Reporting API: CSP violations, COOP and COEP violations, Permissions-Policy and Document-Policy violations, integrity violations, deprecation warnings, browser interventions and renderer crashes. Deprecation, intervention and crash reports need no per-feature directive; they go to the default endpoint, the one you declare under the name default, which catches every report type with no explicit target. Network errors (NEL) are separate: Chromium-only, configured by the NEL header, delivered through a Report-To group. ## 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. [Start with CentralCSP](https://app.centralcsp.com) [Collect the reports you just verified](https://centralcsp.com/en/platform/monitoring/) --- Available in: [en](https://centralcsp.com/en/tools/reporting-api/), [fr](https://centralcsp.com/fr/tools/reporting-api/)