Reporting-Endpoints: where browser reports are sent
Reporting-Endpoints names URLs the browser can post reports to, so other headers such as Content-Security-Policy can reference a collector by name instead of repeating a URL.
At a glance
- Direction
- Response only. Reports are delivered later, by the browser, as separate POST requests.
- Defined in
- Reporting API (W3C). It supersedes the JSON based Report-To header.
- When absent
- Nothing is collected. Violations appear only in the console of whoever happens to be looking.
- Syntax
- name="https://example.com/path", one or more comma separated pairs
- Referenced by
- The report-to directive in Content-Security-Policy and other policy headers
- Delivery
- Batched and out of band, with a content type of application/reports+json
- Older form
- Report-To, which carried a JSON object with a group name and a max_age
In detail
The header is a list of name and URL pairs. Other headers then refer to a name rather than carrying a URL of their own, which keeps one collector definition for a page that has several policies. Reports are queued by the browser and posted separately, so they arrive after the page has finished loading and sometimes after the visitor has gone.
Content-Security-Policy is the main consumer through its report-to directive, but the same mechanism carries deprecation warnings, intervention notices when the browser overrides something the page did, and crash reports. That makes it a useful signal even on a site with no CSP: deprecation reports tell you which browser feature is about to be removed under you, measured from real traffic rather than from your own machine.
It replaces Report-To, which packed a group name, a max_age and an array of endpoints into a JSON string inside a header value. Many sites still send both, because the older CSP report-uri directive and the older header still work in clients that have not moved. Sending all three is untidy but harmless as long as the URLs agree.
The receiving endpoint gets a JSON array with a content type of application/reports+json, not a form post. It must accept POST, must not require credentials, and should answer quickly, since the browser has no interest in the response body and will not retry usefully.
Examples
Reporting-Endpoints: csp-endpoint="https://example.com/reports/csp", default="https://example.com/reports/default"
Content-Security-Policy: default-src 'self'; report-to csp-endpointReport-To: {"group":"csp-endpoint","max_age":10886400,"endpoints":[{"url":"https://example.com/reports/csp"}]}POST /reports/csp HTTP/1.1
Content-Type: application/reports+json
[{"type":"csp-violation","age":12,"url":"https://example.com/checkout","body":{"blockedURL":"https://analytics.example.net/tag.js"}}]Things that catch people out
- The endpoint URL must not require authentication or cookies. Reports are sent without credentials and a redirect to a login page loses them silently.
- Delivery is batched and delayed, so an empty collector minutes after a deploy does not mean the policy is clean.
- A collector on a different origin has to accept the preflight for a JSON content type, or nothing arrives at all.
Try it: HTTP Headers Checker
Check a live URL or paste headers you already have. It grades six security headers from A+ to F and lists every other header the response returned.
HTTP Headers Checker
LOCAL · Browser-OnlyView HTTP response headers for any URL
Enter any website URL to fetch and analyze its HTTP response headers. We'll automatically add https:// if needed.
Why Check Security Headers?
Security headers protect your website against common attacks like XSS, clickjacking, and MIME sniffing. They're set by your web server and cost nothing to implement. Missing security headers are one of the most common findings in security audits.
Related HTTP headers
All http headers →Content-Security-Policy-Report-Only: testing a policy safely
How the report-only CSP header measures a policy without blocking anything, where the violation reports go, and when to run it alongside an enforcing policy.
Content-Security-Policy: directives, sources and reporting
How CSP directives are matched, what default-src actually falls back to, why unsafe-inline defeats the point of a policy, and how nonces and hashes work.
Server-Timing: server side metrics in the response
How to report server side durations to the browser, the dur and desc parameters, what it costs to expose them, and how to read them cross-origin.
Permissions-Policy: turning browser features off by default
How Permissions-Policy allowlists are written, the empty parentheses that disable a feature, and how the syntax differs from the Feature-Policy header.
Sec-Fetch-Site and the Fetch Metadata request headers
What the browser tells your server about where a request came from and what it is for, and how to use Fetch Metadata headers to reject cross-site requests.
Cache-Control: directives for browsers and shared caches
Every Cache-Control directive that matters, the difference between no-cache and no-store, and how to cache immutable assets forever without breaking deploys.
Tools for this
- HTTP Headers Checker Free online HTTP headers checker - view HTTP response headers for any URL
- HTTP Request Builder Free online HTTP request builder - build and test HTTP requests with custom headers and body