Reporting-Endpoints is a data export boundary, not just a monitoring header

The Reporting API gives a web origin a structured way to tell the browser where to send reports. A Reporting-Endpoints response header defines endpoint groups, and policy features such as Content Security Policy or Network Error Logging select a group. The reports can be valuable. They can also disclose URLs, server addresses, protocol details, and security policy behavior to every service that receives them.

The Reporting API defines a report as data the browser is expected to deliver to a specified endpoint. Each report has a type, timestamp, destination, URL in some cases, and a body with feature-specific fields. Delivery is not a transactional application write. It is a browser-mediated report flow with retries, privacy boundaries, and rate limits.

Treat the collector as an external service

Choose the collector host deliberately. A reporting endpoint on a separate origin can keep reports available when the main application is failing. That separation also means the browser is sending data outside the application origin. Require HTTPS, review the certificate path, and document which organization owns the collector.

A CSP violation report may contain the blocked URL, the policy directive, and the document or worker context. A NEL report can contain a referrer, server IP, protocol, HTTP method, status code, and failure phase. Those fields are useful for diagnosis, but they can reveal internal hostnames, paths, or network topology. Apply a retention period and an access policy to the collector.

Do not put a reusable secret in the public reporting header. The browser and any network observer can see the endpoint group configuration. If the collector needs authentication, use a mechanism that fits the browser's constrained request flow and does not turn the header into a credential store.

Bound the queue and the traffic

Reports are not guaranteed to arrive immediately. The browser may retain them and retry after connectivity returns. The specification uses a best-effort delivery model, so absence of a report is not proof that no violation occurred. A collector that assumes every blocked request produced a report will undercount.

Set sampling and retention intentionally. NEL allows separate success and failure sampling fractions. A high-volume site can generate more reports than a collector can store. Rate-limit at the edge, aggregate by report type, and preserve a bounded sample for investigation. Do not discard all reports during an incident merely because the queue is full.

Use multiple endpoint groups when different teams own different policies. A CSP report and a network error report may need different retention and access. Keep the endpoint names stable and review changes as configuration, not as a silent deployment detail.

Validate the browser evidence

A report is browser-generated evidence about a request or policy decision. It is not a server access log and it does not contain the full state of the page. Correlate the report with server logs using a bounded request ID or timestamp when possible. Never put sensitive session values in the report URL to make correlation easier.

Test the collector with a report-only policy, a blocked resource, a network failure, and an invalid endpoint. Confirm that the policy fails closed where required and that the report-only path does not change enforcement. Check the report body against the specification version used by the browser.

Record the endpoint group, report type, policy, retention owner, sampling rate, and collector host. Review who can read the reports and how they are deleted. Reporting is a security control only when the data arrives, stays within its intended boundary, and leads to an action.

References

• W3C Reporting API
• W3C Content Security Policy Level 3
• W3C Network Error Logging