report-to
The CSP report-to directive names a reporting endpoint group from Reporting-Endpoints to receive violation reports.
Last update:
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 header, not a URL. It is the modern replacement for 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:
Reporting-Endpoints: csp-endpoint="https://<Endpoint-ID>.report.centralcsp.com"Content-Security-Policy:
default-src 'self';
report-to csp-endpointFallback 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
A single endpoint group name (a token), referencing a group in 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
To also cover old browser versions that predate report-to, keep a report-uri fallback in the same policy; browsers that understand report-to ignore it:
Content-Security-Policy:
default-src 'self';
report-to csp-endpoint;
report-uri https://<Endpoint-ID>.report.centralcsp.comThe browser then delivers a csp-violation report as a JSON array of camelCase objects. See the CSP violation report page for the field reference and how it differs from the legacy report-uri payload.
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.
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
Content-Security-Policy:
default-src 'self';
report-to csp-endpointUse 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 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, which is a different, deprecated mechanism, still required only for NEL. The directive pairs with Reporting-Endpoints, not with that header.
Reporting
report-to is the reporting wiring itself: it routes each violation to your endpoint group as a csp-violation report delivered through the Reporting API.
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
- report-uri directive
- Content-Security-Policy-Report-Only header
- Reporting-Endpoints header
- Report-To header (legacy Reporting API)
- report-uri vs report-to