Reporting-Endpoints header, syntax and examples

The modern header that declares named reporting endpoints for CSP, COOP, COEP, and other browser policies.

Reporting-Endpoints is the response header that names the URLs where the browser should send reports. You give each endpoint a name, then policies like Content Security Policy (CSP), COOP, and COEP reference that name to route their reports. It is the modern replacement for the legacy Report-To header.

Reporting-Endpoints: csp-endpoint="https://<Endpoint-ID>.report.centralcsp.com"

Content-Security-Policy: default-src 'self'; report-to csp-endpoint

What is the Reporting-Endpoints header

It is a structured-field dictionary: a comma-separated list of name="url" pairs. The name is an arbitrary label you choose; the value is the endpoint URL in quotes. Declaring an endpoint does nothing on its own. Reports only flow once a policy names one of these endpoints, so the header and a policy always work as a pair.

Values and what each does

Value	Status	Description
`name="https://url/"`	✅ Good	A named endpoint mapping. A policy references it by `name`.
An HTTPS endpoint URL	✅ Good	Where reports are POSTed. Must be HTTPS (potentially trustworthy).
An `http://` endpoint	❌ Risky	Non-secure URL. The browser ignores it, so reports vanish. Use HTTPS.
`a="url1", b="url2"`	✅ Good	Several comma-separated endpoints; route different policies to different URLs.
`default="https://url/"`	✅ Good	The fallback endpoint for report types with no explicit target (deprecation, intervention, crash).

Reporting-Endpoints: default="https://<Endpoint-ID>.report.centralcsp.com",
                     csp-endpoint="https://<Endpoint-ID>.report.centralcsp.com"

If your deprecation or crash reports never arrive, the usual cause is a missing default endpoint, those types do not use a named one. See the default endpoint for how the fallback resolves.

Insecure values to avoid

The endpoint URL must be HTTPS (potentially trustworthy). The browser silently ignores a non-secure HTTP endpoint and an invalid URL, so a misconfigured value means reports vanish with no error.

No parameters are defined for an endpoint, and any extra parameters are silently ignored. Point endpoints only at hosts you control or trust: report bodies can include page URLs and short samples of inline content, so an untrusted endpoint is a data-leak path.

Why this header exists

It replaces Report-To with a simpler model. Report-To carried endpoint groups, caching, and failover that never got standardized and only ever shipped in Chromium. Reporting-Endpoints is a plain, per-response name="url" map, which fits how policies are delivered (per response) and which other browser engines have a path to adopt. See Report-To vs Reporting-Endpoints.

What it protects against

Nothing directly, the header enforces no policy. What it provides is visibility: it is the wiring that turns an otherwise silent policy violation, network error, or deprecation into a signal you can collect, monitor, and alert on. The protection comes from the policy; this header is how you learn the policy fired.

Known bypasses and limitations

The header only affects the document it is served on, so it must be present on every response that can generate a report; serving it on the home page alone leaves the rest of the site silent. There is no max_age caching, no endpoint groups, and no failover (one URL per name). And it does not deliver Network Error Logging reports, which still require Report-To.

Risks of misconfiguration

The failure mode is silent. A typo in the endpoint name means a policy's report-to resolves to nothing and no reports are sent, with no error anywhere. A header missing from some responses gives you partial coverage that looks like low traffic rather than a gap.

Recommendation

Declare one clearly named HTTPS endpoint and reference it from each policy. A single csp-endpoint covers the common case; add a default only when you also collect the browser-emitted reports (deprecation, intervention, crash).

Reporting-Endpoints: csp-endpoint="https://<Endpoint-ID>.report.centralcsp.com"

The endpoint URL has to be HTTPS. The Reporting API only accepts a potentially trustworthy endpoint, and the browser drops an http:// URL with no error. Serve the same header on every response that can generate a report so coverage is complete.

How to set it up

Add the header on every response that should report, name one or more endpoints, and reference them from each policy. To confirm a live site is wired correctly without building a receiver, use the Reporting API configuration checker; to collect and aggregate the reports without standing up a backend, point the endpoint at CentralCSP reporting.

Browser support

Baseline 2026: Reporting-Endpoints and the CSP report-to directive are widely supported in current browsers, including Chrome, Edge, Firefox, and Safari (and their mobile equivalents), so report delivery through the Reporting API is no longer Chromium-only. Network Error Logging is the exception: it still requires the legacy Report-To header and remains Chromium-only.

Reporting-Endpoints header