Report-To header, the legacy reporting endpoint format

The legacy header for declaring reporting endpoint groups, superseded by Reporting-Endpoints but still required for NEL.

Report-To is the original header for telling the browser where to send reports. It defines endpoint groups in JSON, with caching and failover. It has been superseded by the simpler Reporting-Endpoints header for almost every use, and the one place you still need it is Network Error Logging (NEL).

Deprecated and non-standard

Report-To never became a web standard and shipped only in Chromium-based browsers. Use Reporting-Endpoints instead, except for NEL, which still requires this header.

Report-To: { "group": "csp-endpoint", "max_age": 10886400,
             "endpoints": [ { "url": "https://<Endpoint-ID>.report.centralcsp.com" } ] }

Values and what each does

The value is JSON: an array of group objects with the outer brackets omitted, so a single group is written without surrounding [ ]. Each group has these members:

Member	Status	What it does
`group`	⚠️ Deprecated	The name a policy references, the legacy equivalent of an endpoint name in `Reporting-Endpoints`.
`max_age`	⚠️ Deprecated	Seconds to cache this configuration, the ambient model that v1 dropped.
`endpoints`	⚠️ Deprecated	An array of URL objects, optionally with `priority` and `weight` for failover.
`include_subdomains`	⚠️ Deprecated	Apply the configuration to subdomains as well.

Insecure values to avoid

Endpoints must be HTTPS. A long max_age caches the config and an attacker who can set headers on one response could keep stale endpoints alive, so scope it sensibly.

As with any reporting endpoint, point it only at a host you trust; report bodies can carry URLs and content samples.

Why this header exists

Report-To was the first Reporting API delivery mechanism. Its grouping, caching, and load-balancing model proved to be more than other browser engines wanted to standardize, so the simpler Reporting-Endpoints (v1) replaced it. See Report-To vs Reporting-Endpoints.

What it protects against

Nothing directly. Like Reporting-Endpoints, it enforces no policy; it is the transport that makes policy violations and network errors observable. The value is visibility, not enforcement.

Known bypasses and limitations

It is Chromium-only and never shipped in Firefox or Safari, and it is superseded for everything except NEL. Treat it as legacy: use it only where you must.

Risks of misconfiguration

The failures are silent. A malformed JSON value disables reporting with no error, and a group name that does not match what a policy (or the NEL header) references means those reports go nowhere.

Recommendation

Use Reporting-Endpoints for every policy, CSP, COOP, COEP, Permissions-Policy, and the rest. Keep Report-To for one job: Network Error Logging still reads its endpoint group from this header, so a site that uses NEL sends both headers together.

Report-To: {"group":"nel-group","max_age":31536000,"endpoints":[{"url":"https://<Endpoint-ID>.report.centralcsp.com"}]}

NEL: {"report_to":"nel-group","max_age":31536000,"include_subdomains":true}

How to set it up

The one case that still needs Report-To is NEL. The NEL header's report_to member names a group defined here, and the two headers are sent together. Point the group's endpoint at CentralCSP reporting to collect the network-error stream alongside your other reports.

Report-To: {"group":"nel-group","max_age":31536000,"endpoints":[{"url":"https://<Endpoint-ID>.report.centralcsp.com"}]}

NEL: {"report_to":"nel-group","max_age":31536000,"include_subdomains":true,"failure_fraction":1.0}

Browser support

Chromium-based browsers only (Chrome, Edge, and others); it never shipped in Firefox or Safari, and the W3C Reporting specification does not define it. For anything other than NEL, use Reporting-Endpoints instead.

Report-To header