# Reporting-Endpoints header (/en/docs/web-security/reporting-api/headers/reporting-endpoints) `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)](/en/docs/web-security/policies/content-security-policy), [COOP](/en/docs/web-security/policies/cross-origin-opener-policy), and [COEP](/en/docs/web-security/policies/cross-origin-embedder-policy) reference that name to route their reports. It is the modern replacement for the legacy [`Report-To`](/en/docs/web-security/reporting-api/headers/report-to) header. ```http Reporting-Endpoints: csp-endpoint="https://.report.centralcsp.com" ``` ```http Content-Security-Policy: default-src 'self'; report-to csp-endpoint ``` ## What is the Reporting-Endpoints header [#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 [#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). | ```http Reporting-Endpoints: default="https://.report.centralcsp.com", csp-endpoint="https://.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](/en/docs/web-security/reporting-api/concepts/default-endpoint) for how the fallback resolves. ## Insecure values to avoid [#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 [#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](/en/docs/web-security/reporting-api/concepts/report-to-vs-reporting-endpoints). ## What it protects against [#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 [#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`](/en/docs/web-security/reporting-api/headers/report-to). ## Risks of misconfiguration [#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 [#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). ```http Reporting-Endpoints: csp-endpoint="https://.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 [#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](/tools/reporting-api); to collect and aggregate the reports without standing up a backend, point the endpoint at [CentralCSP reporting](/en/docs/platform/monitoring). ## Browser support [#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. ## See also [#see-also] * [Report-To header](/en/docs/web-security/reporting-api/headers/report-to) * [Report-To vs Reporting-Endpoints](/en/docs/web-security/reporting-api/concepts/report-to-vs-reporting-endpoints) * [The report delivery format](/en/docs/web-security/reporting-api/concepts/report-delivery-format) * [Policies](/en/docs/web-security/policies) * [Where browser reports go and how to receive them](/en/blog/where-to-send-csp-reports) ## Sources [#sources] * [MDN, Reporting-Endpoints header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Reporting-Endpoints) * [W3C, Reporting API](https://www.w3.org/TR/reporting-1/) * [Chrome, migrate to Reporting API v1](https://developer.chrome.com/blog/reporting-api-migration)