Reporting API: receive browser reports safely

What reporting provides

The Reporting API describes a shared delivery mechanism for certain browser reports. It works in the background on a best-effort basis: reports can be delayed, batched or discarded. It is not a reliable messaging channel. A missing report therefore does not mean that no error or attack occurred. Reporting draft §1.1

Generating a report and enforcing a protection rule are separate. An enforced Content Security Policy can block a resource and also generate a report. A Content-Security-Policy-Report-Only reports potential violations but does not enforce that policy. Conversely, protection can be effective even when the report does not arrive. The CSP guide and the article on COOP, COEP and CORP explain the protection rules.

Consider report type and support together

Not every browser generates every type. A JavaScript interface such as ReportingObserver also observes only the report types exposed to it. An entry visible there does not prove receipt by the server. For CSP, the securitypolicyviolation event provides another way to observe a local violation. This helps diagnosis but does not replace delivery testing.

Distinguish three similarly named components

The current Reporting specification is a W3C draft, not an IETF RFC or a completed W3C Recommendation. Its Reporting-Endpoints does not automatically replace every use of Report-To: NEL is not part of the document-centred v1 path in the documented Chromium implementation. A blanket “always set both headers” is therefore as inappropriate as “remove Report-To everywhere immediately”. What matters is the report types and target browsers you actually need. Reporting draft, Chrome migration guidance

Start with a limited CSP test

This example describes an HTTPS test page. Replace the placeholder domain with a receiver you control and have configured. The image policy is deliberately narrow and is not a complete CSP design:

Reporting-Endpoints: csp="https://reports.example/csp"
Content-Security-Policy-Report-Only: img-src 'self'; report-to csp; report-uri https://reports.example/csp-legacy

The name csp must match exactly. The double quotation marks around the endpoint URL are part of the header syntax. On this test page, the policy reports an image from another origin without blocking it through this Report-Only rule. Other existing protection policies continue to apply.

report-uri provides compatibility here for browsers that do not support the newer CSP reporting path. A browser supporting report-to ignores the accompanying report-uri directive. It is therefore not an automatic fallback for an incorrectly named or failed report-to receiver. The two routes must also accept different message formats: modern reports as an array with application/reports+json, older CSP reports as an object with application/csp-report.

Configure headers on the actual document responses. Setting them only on a redirect or an arbitrary resource response is not sufficient for all subsequent pages. Also check whether the CDN, proxy or application overwrites the configuration.

Use NEL deliberately, with a short trial period

NEL needs a policy previously accepted by the browser. A failed very first visit cannot learn configuration from a response never received. Error reports can also suffer the same network outage as the website. Independent availability checks require additional measurements.

A limited configuration example for the documented Chromium path:

Report-To: {"group":"network","max_age":86400,"endpoints":[{"url":"https://reports.example/network"}]}
NEL: {"report_to":"network","max_age":86400,"success_fraction":0,"failure_fraction":1}

The one-day lifetime is a deliberate example choice for introduction, not a general standard. The group must match, and its receiver configuration must not become unusable before the NEL policy does. success_fraction: 0 selects no successful requests. failure_fraction: 1 generally selects all applicable failures but does not guarantee complete delivery. For high traffic volumes, plan volume, sampling and retention together.

include_subdomains is deliberately absent: include subdomains only after an explicit decision. Extending coverage requires suitable receiver-side configuration and responsibility for the affected applications. To remove a stored NEL policy, send NEL: {"max_age":0} from the relevant origin; a separately stored Report-To group has its own lifecycle. Merely omitting the header from future responses does not immediately remove policies already stored.

NEL error types are diagnostic data. For example, with multiple server addresses, dns.address_changed can result from a privacy-related reduction of report information. This alone establishes neither DNS manipulation nor an attack. NEL draft §§4–7

Browser support: check configuration and report type separately

Browser Compatibility Data reviewed on 27 September 2026:

These entries describe each specific feature. They establish neither every report type nor the operation of a particular endpoint. Firefox illustrates why recognising Reporting-Endpoints must not be equated with CSP reports. The versions, WebViews and enterprise policies your visitors actually use matter. Do not treat other Chromium products as fully tested based on their product name alone. BCD: Reporting-Endpoints, CSP, NEL

Operate a receiver that processes reports safely

The endpoint must treat incoming data as untrusted: other clients can also send fabricated reports. Limit payload size, volume, processing cost and stored fields. Validate the schema and report type, handle unknown fields robustly and do not display strings as unfiltered HTML. A successful unauthenticated POST does not establish that its contents are authentic.

Modern reports arrive as a JSON array, potentially containing several entries. The age field describes the report's age in milliseconds, not an absolute timestamp. Responses in the 200–299 range acknowledge acceptance at the transport level; the Reporting draft gives 410 Gone the specific meaning of removing the endpoint. Your application must still reliably process an input it has successfully acknowledged.

For a receiver on another origin, the CORS preflight must also work. Modern delivery uses the credentials mode same-origin: same-origin receivers can receive cookies, while other origins receive no credentials through this path. CORS does not authenticate the reporting browser. Check response headers and permitted methods/headers at the collector actually used. Reporting draft §3.5, Chrome operational guidance

Reports may contain document URLs, resource addresses, referrers, browser details and further information depending on the type. Removing the username, password and fragment from a URL does not make it anonymous: paths and query parameters may still contain confidential data. CSP samples and additional NEL header fields can increase the content further. Avoid placing such data in URLs in the first place and retain only the fields you need. Define purpose, access, retention, deletion and any arrangements with a service provider. A period such as “30 days” is not a general statutory requirement for browser reports.

Test generation, delivery and analysis separately

1. Provide an isolated test page with a known policy, named endpoint and deliberately triggered violation.
2. Use browser tools or appropriate events to check whether the policy was processed and the report generated.
3. At the receiver, check whether a real browser report arrives with the correct type and reference to the test page. Record the waiting period, browser and version.
4. Test an incorrect endpoint name and an unreachable receiver as countercases. Do not count missing reports as successful protection testing.
5. Trace received reports from transport through to analysis. Sampling, rate limits and filters can further change the visible count.

A manually sent curl POST tests only the receiver. An earlier local HTTPS check with Chromium 147 observed CSP violations and modern reports in the browser queue, but received only one legacy report within 90 seconds. In an additional local diagnostic check on 28 September 2026 using Chrome 153.0.8010.54, actual modern CSP reports arrived as application/reports+json at our collector, both in an isolated normal profile and in a private context. With a deliberately incorrect endpoint name, no corresponding report or legacy fallback arrived during the 35-second observation window.

The additional check used Chrome's documented --short-reporting-delay option. It establishes receipt in that local HTTPS setup with a same-origin collector, not a normal delivery interval or verified operation of an external receiver. It does not isolate the precise cause of the earlier absence; in particular, profile type alone does not explain the difference. For your own check, record the report type, browser version, profile and receiver, and verify actual arrivals. Chrome: diagnose your reporting configuration

What the Wolf-Agents finding establishes

In the reviewed product version, the Web Security Check considers visible values of Report-To, NEL and Reporting-Endpoints in its assessment. It does not run a browser, trigger a relevant policy violation or verify a collector. Even a syntactically unusable but non-empty value can count as a present header in this evaluation. A positive finding therefore indicates configuration, not functioning monitoring. Conversely, a missing header is not a security vulnerability in itself.