Cybersecurity glossary
What are Reporting-Endpoints?
Learn what the Reporting-Endpoints HTTP header does, how it maps report types to collector URLs, how it replaces Report-To, and how to configure CSP and COOP reporting safely.
Definition
Reporting-Endpoints is an HTTP response header that registers named collector URLs for the Reporting API, letting browsers know where to send structured reports such as Content Security Policy violations, COOP issues, and deprecation warnings.
Why Reporting-Endpoints matters
Content Security Policy and related headers are only useful in production if teams see violations. Scattered legacy report-uri values and ad hoc logging make that hard to operationalize.
The Reporting-Endpoints header centralizes collector configuration. One declarative header tells the browser which HTTPS URLs receive which report types—so CSP, COOP, and other features share a consistent monitoring pipeline.
How Reporting-Endpoints works
Server emits Reporting-Endpoints
The response lists named groups mapped to collector URLs, for example csp-endpoint and coop-endpoint.
Security policies name a group
CSP includes report-to or endpoint directives that reference a registered name.
Browser matches name to URL
When a reportable event occurs, the client resolves the group to your collector.
Report POST is queued
Delivery is asynchronous with batching and browser-side throttling.
Collector processes JSON
Your service ingests, deduplicates, and forwards events to dashboards or alerts.
Header syntax patterns
Named endpoints
Each entry pairs a short name with a quoted HTTPS URL the browser may contact.
Multiple groups
One header line can register several collectors for CSP, COOP, and deprecations.
CSP integration
Content-Security-Policy references the csp-endpoint group instead of inline report-uri URLs.
Report-Only mode
Report-Only policies use the same endpoints to tune rules before enforcement.
Dedicated subdomain
Many teams host collectors on reports.example.com isolated from the app origin.
Migration from Report-To
During transition, verify browsers in your audience support Reporting-Endpoints.
Configuration examples by goal
| Goal | Typical setup | Note |
|---|---|---|
| CSP tuning before enforce | Reporting-Endpoints + Content-Security-Policy-Report-Only | Watch reports for a week before blocking |
| Production CSP monitoring | Same endpoint name in enforcing CSP | Alerts on unexpected new violation sources |
| COOP diagnostics | Separate coop-endpoint collector | Keeps opener issues distinct from script violations |
| Multi-tenant SaaS | Per-tenant collector paths or shared pipeline with tenant tags | Avoid cross-customer report leakage in storage |
Security checklist
- Publish Reporting-Endpoints on every HTML response that emits policies referencing those groups.
- Use HTTPS collectors with TLS you control; do not point at third-party analytics without review.
- Keep endpoint names stable across deploys so historical dashboards stay comparable.
- Validate inbound report JSON and cap request body size at the edge.
- Separate staging and production collector URLs to prevent test noise in on-call pages.
- Remove obsolete Report-To headers after verifying browser support in your user base.
- Redact or avoid logging full report bodies in shared application logs.
- Test end-to-end by triggering a known-safe CSP violation in a controlled environment.
Limits and pitfalls
Misaligned names between Reporting-Endpoints and your CSP report-to reference silently drop reports. Typos in endpoint names are a common rollout failure.
Browsers may coalesce or delay delivery. Incident response cannot rely on sub-second report latency.
Pointing collectors at origins that require cookies or session auth often fails—browsers send reports as simple cross-origin POSTs without your app’s normal authentication context. Design collectors to accept anonymous ingestion with other protections.
The practical takeaway
Reporting-Endpoints is the configuration layer for browser security telemetry. It tells clients where to send CSP and related reports so policies become observable.
Define collectors deliberately, wire them into Report-Only rollouts first, and operate ingestion as security infrastructure—not an afterthought URL in a single directive.
Related security terms
Reporting API
The browser API that delivers queued reports to URLs defined in Reporting-Endpoints.
Content Security Policy (CSP)
Uses registered endpoints to send violation reports during Report-Only and enforcing modes.
Cross-Origin-Opener-Policy (COOP)
Can reference reporting endpoints when opener isolation checks fail.
Cross-Origin-Embedder-Policy (COEP)
Part of the cross-origin isolation stack often monitored alongside CSP reports.
Frequently asked questions
What is Reporting-Endpoints in simple terms?
It is a response header that lists nicknames and URLs where the browser should POST automatic security and diagnostics reports for your site.
How do I configure a CSP report collector?
Add a line in Reporting-Endpoints such as csp-endpoint="https://reports.example/csp", then reference that name in your Content-Security-Policy or Report-Only header.
Is Reporting-Endpoints the same as Report-To?
Report-To was an older JSON header format. Reporting-Endpoints is the modern, simpler syntax browsers are moving toward for registering collectors.
Can one endpoint handle multiple report types?
You can map different names to the same URL or separate URLs per type. Separate endpoints simplify routing and retention policies.
Must collectors be same-origin?
No. Collectors are often hosted on a dedicated reporting subdomain, but they should be HTTPS and hardened like any security-sensitive API.
What happens if Reporting-Endpoints is missing?
Policies that reference report groups will have nowhere to send data. Browsers will not invent a default collector.
References
Explore authoritative guidance and frameworks related to reporting-endpoints.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.