The Reporting-Endpoints HTTP Header
The
Each name is an identifier; the value is the endpoint URL. Endpoints must use HTTPS. The CSP header then references the name:
Reporting-Endpoints HTTP response header defines named endpoints where the browser can send reports, including Content Security Policy violation reports and other Reporting API report types. Adopting this header improves website maintenance, security, and compliance by centralizing how you receive and process CSP violations and related data. CentralCSP uses it to collect CSP violation and sha-XXX-style reports in one place.
What Is the Reporting-Endpoints Header?
Reporting-Endpoints is a modern replacement for the deprecated Report-To header. You define one or more named endpoints; other mechanisms (such as CSP's report-to directive) refer to those names. When a report is generated, the browser sends it to the corresponding URL.
Syntax:
Example Reporting-Endpoints header
Reporting-Endpoints: csp-endpoint="https://report.centralcsp.com/<your-endpoint>"CSP sending reports to the csp endpoint
Content-Security-Policy: default-src 'self'; report-to csp-endpoint;Benefits for Maintenance, Security, and Compliance
- Centralized reporting : One endpoints receive violation reports from all policies and pages. You can route them to a single service (e.g. CentralCSP) for aggregation, dashboards, and alerting..
- Security : Violation reports show what was blocked (or would be blocked in report-only mode). You can spot attacks, misconfigurations, or compromised scripts and fix policies or code. Alerting on top of these reports shortens response time.
- Compliance : Auditors and frameworks (e.g. PCI DSS) often expect evidence of monitoring and response. A defined reporting pipeline and a platform that stores and analyzes CSP (and related) reports demonstrates that you collect and act on security signals.
How CentralCSP Uses Reporting-Endpoints
CentralCSP is built to receive CSP violation reports and, where supported, other report types (e.g. script hash reports). When you configure your policy withreport-to pointing to an endpoint name that sends to CentralCSP (or use a CentralCSP-provided endpoint URL in your reporting setup), CentralCSP:
- Collects violation reports so you can see what's blocked and where
- Correlates data for Script Inventory, CVE detection, and alerting
- Helps you iterate on your policy using real traffic instead of guesswork
Reporting-Endpoints header (and CSP report-to) is the recommended way to feed that pipeline so you get consistent, structured reports in one place.
Setting It Up
- Choose an endpoint URL : For CentralCSP, use the reporting URL provided for your account/domain (e.g. in the reporting or setup docs).
- Add the header : Send
Reporting-Endpointswith at least one named endpoint, e.g.csp="https://your-endpoint". - Point CSP to it : In your
Content-Security-PolicyorContent-Security-Policy-Report-Onlyheader, addreport-to csp(or whatever name you used). - Verify : Trigger a test violation and confirm reports appear in CentralCSP. Use report-only first so you don't block real traffic while testing.
report-uri; you can send both report-to and report-uri during a transition period. Prefer report-to with Reporting-Endpoints for new implementations.
See also
- Reporting Endpoints : CSP reporting endpoints in the docs
- report-to : How CSP uses report-to with the Reporting API
- Get started with reporting : End-to-end reporting setup
- Alerting in CentralCSP : Acting on reports in real time
Continue Reading
Stay safe, no more unsafe-inline
Learn more about unsafe-inline and how to properly setup your CSP to avoid using it.
2024-12-03
5 min read
Theotime QuereRead more
CSP and GA/GTM
Learn how to properly setup your Content-Security-Policy to ensure a secure configuration with Google Analytics and Google Tag Manager. See how to use 'strict-dynamic' to allow Google script to be loaded.
2024-12-03
5 min read
Theotime QuereRead more
