Limited availability
The HTTP Reporting-Endpoints response header allows website administrators to specify one or more endpoints that can be sent reports generated by the Reporting API.
The endpoints can be used, for example, as targets for sending CSP violation reports, Cross-Origin-Opener-Policy reports, or other generic violations.
When used for reporting Content Security Policy (CSP) errors, the header is used in combination with the Content-Security-Policy header report-to directive. For more details on setting up CSP reporting, see the Content Security Policy (CSP) documentation.
Note: This header replaces Report-To Deprecated for declaring endpoints, and should be used in preference.
Reporting-Endpoints: <endpoint>
Reporting-Endpoints: <endpoint>, â¦, <endpointN>
<endpoint>
A reporting endpoint in the format <endpoint-name>="<URL>". The endpoints must have valid URIs in quoted strings (e.g., my-endpoint="https://example.com/reports") and non-secure endpoints are ignored. A comma-separated list of endpoints may be provided.
The following example shows how the Reporting-Endpoints response header is used in conjunction with the Content-Security-Policy header to indicate where CSP violation reports are sent:
Reporting-Endpoints: csp-endpoint="https://example.com/csp-reports"
Content-Security-Policy: default-src 'self'; report-to csp-endpoint
It's possible to specify multiple endpoints that can be used for different types of violation reports.
Reporting-Endpoints: csp-endpoint="https://example.com/csp-reports",
permissions-endpoint="https://example.com/permissions-policy-reports"
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.3