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

> The default endpoint in Reporting-Endpoints does not collect everything. CSP, COOP, COEP and Permissions-Policy each route themselves, deprecations and crashes fall through to default, and NEL still needs the old header. What lands where, and what gets dropped.

- Canonical: https://info.centralcsp.com/articles/reporting-endpoints-all-report-types/
- Published: 2026-09-21
- Language: en
- Publisher: CentralCSP (https://centralcsp.com)

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.

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

| Report type | Generated when | Routed by |
| --- | --- | --- |
| `csp-violation` | A directive blocks a resource or inline script | `report-to` inside the CSP header |
| `csp-hash` | A script executes, reported with its SHA-256 | `'report-sha256'` in the CSP, same `report-to` |
| `integrity-violation` | An SRI `integrity` attribute fails to match | The CSP's `report-to` |
| `permissions-policy-violation` | A feature blocked by Permissions-Policy is used | `report-to` in the Permissions-Policy header |
| `document-policy-violation` | A Document-Policy configuration is breached | `report-to` in the Document-Policy header |
| `coop` | A cross-origin opener access is blocked or would be | `report-to` in Cross-Origin-Opener-Policy |
| `coep` | A cross-origin resource is blocked by COEP | `report-to` in Cross-Origin-Embedder-Policy |
| `connection-allowlist` | A connection outside the declared allowlist | The policy header that declares the allowlist |
| `deprecation` | A deprecated web API is called | `default` |
| `intervention` | The browser overrides the page for the user's sake | `default` |
| `crash` | The renderer dies, reported on next visit | `default` |
| `network-error` (NEL) | A request fails at the network layer | The `NEL` header, via the legacy `Report-To` |

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:

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

```http
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](/articles/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:

```http
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](/articles/script-inventory-without-an-agent/) 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](https://centralcsp.com/en/blog/changelog): 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](https://centralcsp.com/en/tools/reporting-api/) 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](https://centralcsp.com/en/docs/web-security/reporting-api/headers/reporting-endpoints) if you want the spec text rather than the field notes.

## Frequently asked questions

### Does the default endpoint receive CSP violations?

Only if your policy asks it to. A CSP violation goes to the endpoint named in the policy's own report-to directive, and if that directive is absent the violation is generated and then discarded. Naming an endpoint default in the Reporting-Endpoints header does not retroactively capture CSP reports. Add report-to default to the policy itself.

### Why am I getting deprecation reports I never asked for?

Deprecation, intervention and crash reports have no header of their own to route them, so they fall through to whichever endpoint is named default. Declare a default endpoint and you have subscribed to all three. If you only want CSP, name your endpoint something else and point the policy at it by name.

### Why does my NEL endpoint receive nothing?

Network Error Logging never migrated to Reporting-Endpoints. It still reads the deprecated Report-To header, so a site that has cleanly moved to Reporting-Endpoints has silently turned NEL off. You need both headers side by side, and even then only Chromium browsers send NEL.

### Can one endpoint URL collect every report type?

Yes. Nothing in the spec requires a separate URL per type, and every report arrives as application/reports+json with a type field that says which one it is. Splitting by URL only makes sense if different teams own different surfaces. Otherwise one endpoint and one filter in the collector is less to maintain.