# report-to (/en/docs/web-security/policies/content-security-policy/directives/report-to)



The `report-to` directive tells the browser which reporting endpoint should receive Content Security Policy (CSP) violation reports. Its value is the name of a group declared in the [`Reporting-Endpoints`](/en/docs/web-security/reporting-api/headers/reporting-endpoints) header, not a URL. It is the modern replacement for [`report-uri`](/en/docs/web-security/policies/content-security-policy/directives/report-uri).

It controls where CSP violation reports go. It does not block or allow any resource. When an enforced policy blocks something (or a report-only policy would have), the browser collects a report and delivers it through the Reporting API to the endpoint group you name here.

One header declares the group and its URL, the other points the policy at it:

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

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

## Fallback chain [#fallback-chain]

`report-to` has no fallback. `default-src` does not cover it. Without it (and without `report-uri`), the policy still enforces but emits no reports.

## Values [#values]

A single endpoint group name (a token), referencing a group in [`Reporting-Endpoints`](/en/docs/web-security/reporting-api/headers/reporting-endpoints). It must match a key in the `Reporting-Endpoints` header on the same response; the browser looks up that group, finds its URL, and queues the report for delivery there.

| Value                | Status | Description                                                                                            |
| -------------------- | ------ | ------------------------------------------------------------------------------------------------------ |
| Endpoint group token | ✅ Good | The name of a group declared in the `Reporting-Endpoints` header on the same response. One token only. |

## Examples [#examples]

To also cover old browser versions that predate `report-to`, keep a [`report-uri`](/en/docs/web-security/policies/content-security-policy/directives/report-uri) fallback in the same policy; browsers that understand `report-to` ignore it:

```http
Content-Security-Policy:
    default-src 'self';
    report-to csp-endpoint;
    report-uri https://<Endpoint-ID>.report.centralcsp.com
```

The browser then delivers a `csp-violation` report as a JSON array of camelCase objects. See the [CSP violation report](/en/docs/web-security/reporting-api/reports/csp-violation) page for the field reference and how it differs from the legacy `report-uri` payload.

## Security notes [#security-notes]

`report-to` cannot be set through a `<meta http-equiv>` element; it is an HTTP response header directive only. The endpoint must be HTTPS. Because reports carry blocked URLs and optional content samples, treat the endpoint as a sink for sensitive data.

You can collect these reports with CentralCSP and verify the header and directive line up with the [Reporting API configuration checker](/tools/reporting-api).

## Known bypasses and risks [#known-bypasses-and-risks]

The directive only reports; it does not enforce anything. If the group name does not match a `Reporting-Endpoints` key, the browser has nowhere to send and silently drops the report. Old browser versions that predate `report-to` support report nothing unless you also keep a `report-uri` directive as a fallback.

## Recommendation [#recommendation]

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

Use `report-to` with `Reporting-Endpoints` as your primary reporting path. It recently became available across current Chrome, Firefox, and Safari (MDN and the Firefox release notes), so keep [`report-uri`](/en/docs/web-security/policies/content-security-policy/directives/report-uri) in the policy only to cover old, unupdated browser versions; browsers that understand `report-to` ignore it.

Do not confuse this directive with the legacy [`Report-To` header](/en/docs/web-security/reporting-api/headers/report-to), which is a different, deprecated mechanism, still required only for NEL. The directive pairs with `Reporting-Endpoints`, not with that header.

## Reporting [#reporting]

`report-to` is the reporting wiring itself: it routes each violation to your endpoint group as a [`csp-violation` report](/en/docs/web-security/reporting-api/reports/csp-violation) delivered through the Reporting API.

## Browser support [#browser-support]

Supported cross-browser: it recently became available across current Chrome (and Chromium-based Edge), Firefox, and Safari. It is no longer Chromium-only, and it reached Baseline in 2026. Keep `report-uri` only as a fallback for very old, unupdated browsers.

## See also [#see-also]

* [report-uri directive](/en/docs/web-security/policies/content-security-policy/directives/report-uri)
* [Content-Security-Policy-Report-Only header](/en/docs/web-security/policies/content-security-policy/report-only)
* [Reporting-Endpoints header](/en/docs/web-security/reporting-api/headers/reporting-endpoints)
* [Report-To header (legacy Reporting API)](/en/docs/web-security/reporting-api/headers/report-to)
* [report-uri vs report-to](/en/blog/report-uri-vs-report-to)

## Sources [#sources]

* [MDN, CSP report-to](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/report-to)
* [W3C, Content Security Policy Level 3](https://www.w3.org/TR/CSP3/)
* [Chrome, the Reporting API](https://developer.chrome.com/docs/capabilities/web-apis/reporting-api)
* [MDN, Firefox release notes](https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/149)
