Does the Reporting-Endpoints default endpoint receive all violations, or only CSP?

The Reporting-Endpoints header looks like it does more than it does. You declare a default endpoint, deploy it, and then spend a week wondering why the CSP violations you can see in DevTools never arrive, while a steady drip of deprecation warnings you never asked for fills the collector instead.

Here is the short version. The default endpoint is a fallback, not a firehose. It receives exactly the report types that have no other way to name a destination: deprecations, interventions and crashes. Everything else routes itself. CSP violations go where the policy’s own report-to directive points, COOP and COEP go where their headers point, and Network Error Logging ignores Reporting-Endpoints entirely and still reads the deprecated Report-To header.

So the answer to the question in the title is no, and the gap is bigger than most people expect.

What the header actually does

Reporting-Endpoints is a naming table. Nothing more.

Reporting-Endpoints: default="https://MyEndpoint.report.centralcsp.com", csp="https://MyEndpoint.report.centralcsp.com"

That declares two names, default and csp, both pointing at the same URL. It does not subscribe you to anything. Subscription happens in the header that generates the report, which refers back to one of these names. The one exception is the set of report types generated by the browser on its own initiative, with no policy behind them, and those go to default because there is nowhere else to send them.

It has been baseline across browsers since September 2024, and it replaced the older Report-To header, which was JSON-in-a-header and genuinely unpleasant to write. Good riddance, with one caveat covered below.

Two things get dropped without a word. Endpoints that are not HTTPS are ignored, silently. And a name you reference from a policy but never declare in Reporting-Endpoints is also ignored, silently. Both failures look identical from the outside: the browser records a violation, you see it in the console, and nothing ever reaches your server. We have lost afternoons to a report-to csp-endpoint pointing at a name spelled csp_endpoint in the other header.

Where each of the twelve types actually goes

Read that last column again. Eight of the twelve need you to add report-to to a header you may not currently send at all. If you only ship a CSP, you get CSP-family reports plus whatever falls to default, and the other six surfaces stay dark no matter how the endpoint is named.

The CSP case, because it is the one people get wrong

Declaring an endpoint does nothing for CSP. The policy has to ask:

Reporting-Endpoints: csp="https://MyEndpoint.report.centralcsp.com"
Content-Security-Policy-Report-Only: default-src 'none'; script-src 'self'; report-to csp

Without that trailing report-to csp, the browser evaluates the policy, logs the violation to the console, and throws the report away. The console output is identical either way, which is why this costs people a week rather than five minutes.

The report-to directive has been baseline across current browsers since March 2026. Before that, report-uri was the only thing that worked everywhere, and it is deprecated but still universally honoured. Our advice has not changed: ship both.

Content-Security-Policy-Report-Only: default-src 'none'; report-uri https://MyEndpoint.report.centralcsp.com; report-to csp

Browsers that understand report-to ignore report-uri when both are present, so you do not get duplicates. Older ones use report-uri and you keep the coverage. The two payloads differ, which matters if you are writing the collector yourself: report-uri sends a single csp-report object with kebab-case fields as application/csp-report, immediately, while the Reporting API batches camelCase objects inside a metadata wrapper as application/reports+json. Two parsers, one endpoint. We go through the differences in report-uri vs report-to vs Reporting-Endpoints.

NEL is the trap in a clean migration

Network Error Logging never moved. It reads the NEL header, and the group name in that header resolves against the deprecated Report-To header, not Reporting-Endpoints.

Which produces a nasty outcome: the tidier your migration, the more likely you broke it. A team that removed Report-To because MDN calls it deprecated has turned off network error reporting without a single log line saying so. To keep NEL you send both headers, old and new, side by side:

Report-To: {"group":"nel","max_age":2592000,"endpoints":[{"url":"https://MyEndpoint.report.centralcsp.com"}]}
NEL: {"report_to":"nel","max_age":2592000,"include_subdomains":true}
Reporting-Endpoints: default="https://MyEndpoint.report.centralcsp.com", csp="https://MyEndpoint.report.centralcsp.com"

Even then, NEL is Chromium only. Firefox and Safari send nothing. That is still worth having, because NEL is the only one of the twelve that reports failures where the browser never reached your server at all: DNS failures, TLS handshake errors, connections dropped by an ISP. Your server logs by definition cannot contain those requests.

What this is worth beyond CSP

The reflex is to treat the other eleven as noise. Some of it is. But three of them earn their keep in a way CSP alone does not.

deprecation tells you which removed-in-two-versions API your third-party analytics vendor is still calling, months before the vendor’s own changelog mentions it. crash gives you renderer deaths from real user machines, on the visit after they happen, which is the only telemetry you will ever get from a tab that died. And csp-hash is the quiet one: every script that actually executed, with its SHA-256, which turns a violation stream into a script inventory built from real traffic rather than a crawl.

Twelve types on one endpoint also means one header change rather than twelve integrations. That was the reasoning behind expanding CentralCSP’s collector from two report types to all twelve in the September 2026 release: the managed endpoint (one subdomain per site, of the form https://MyEndpoint.report.centralcsp.com) accepts every type, both payload formats, and both the modern and legacy routing headers, so the NEL trap above is a configuration you copy rather than a bug you find. Reports arrive deduplicated and grouped by directive and origin, with browser-extension noise flagged, and every raw payload stays queryable in the Explorer for the 90 days it is retained. That is on every plan, starting at Start (€39.99/month, 3 sites, 250,000 reports).

Check your wiring before you wait a week

The failure mode of this whole area is silence, and silence is indistinguishable from “nothing is broken”. Before you assume the site is clean, verify the plumbing: the free Reporting API checker reads your live headers and tells you which of Reporting-Endpoints, Report-To, report-uri and NEL are present, which names resolve, and which report types would be silently dropped as configured. No account, one URL.

Then give it real traffic and see what turns up. A quiet endpoint after a day usually means a name that does not resolve, not a site with nothing to report. The MDN-level detail on the header itself lives in the Reporting-Endpoints reference if you want the spec text rather than the field notes.