Report-To
Deprecated: This feature is no longer recommended. Though some browsers might still support it, it may have already been removed from the relevant web standards, may be in the process of being dropped, or may only be kept for compatibility purposes. Avoid using it, and update existing code if possible; see the compatibility table at the bottom of this page to guide your decision. Be aware that this feature may cease to work at any time.
Non-standard: This feature is non-standard and is not on a standards track. Do not use it on production sites facing the Web: it will not work for every user. There may also be large incompatibilities between implementations and the behavior may change in the future.
Warning: This header has been replaced by the Reporting-Endpoints
HTTP response header.
It is a deprecated part of an earlier iteration of the Reporting API specification.
The HTTP Report-To
response header allows website administrators to define named groups of endpoints that can be used as the destination for warning and error reports, such as CSP violation reports, Cross-Origin-Opener-Policy
reports, deprecation reports, or other generic violations.
Report-To
is often used in conjunction with other headers that select a group of endpoints to use for a particular kind of report.
For example, the Content-Security-Policy
header report-to
directive can be used to select the group used for reporting CSP violations.
Header type | Response header |
---|---|
Forbidden header name | no |
CORS-safelisted response header | no |
Syntax
Report-To: <json-field-value>
- <json-field-value>
-
One or more endpoint-group definitions, defined as a JSON array that omits the surrounding
[
and]
markers. Each object in the array has the following properties:
Examples
Setting a CSP violation report endpoint
This example shows how a server might use Report-To
to define a group of endpoints, and then set the group as the location where CSP violation reports are sent.
First a server might send a response with the Report-To
HTTP response header as shown below.
This specifies a group of url
endpoints identified by the group name csp-endpoints
.
Report-To: { "group": "csp-endpoints",
"max_age": 10886400,
"endpoints": [
{ "url": "https://example.com/reports" },
{ "url": "https://backup.com/reports" }
] }
The server can then specify that it wants this group to be the target for sending CSP violation reports by setting the group name as the value of the report-to
directive:
Content-Security-Policy: script-src https://example.com/; report-to csp-endpoints
Given the headers above, any script-src
CSP violations would result in violation reports being sent to both of the url
values listed in Report-To
.
Specifying multiple reporting groups
The example below demonstates a Report-To
header that specifies multiple endpoint groups.
Note that each group has a unique name, and that the groups are not bounded by the array markers.
Report-To: { "group": "csp-endpoint-1",
"max_age": 10886400,
"endpoints": [
{ "url": "https://example.com/csp-reports" }
] },
{ "group": "hpkp-endpoint",
"max_age": 10886400,
"endpoints": [
{ "url": "https://example.com/hpkp-reports" }
] }
We can select an endpoint group as the target for violation reports by name, in the same way as we did in the previous example:
Content-Security-Policy: script-src https://example.com/; report-to csp-endpoint-1
Specifications
This header is no longer part of any specification. It was previously part of the Reporting API.
Browser compatibility
BCD tables only load in the browser