CentralCSP
Reporting API

The browser Reporting API explained

The browser Reporting API collects policy violations, network errors, deprecations, and crashes and delivers them to an endpoint you choose.

Last update:

The Reporting API is the browser mechanism for collecting events that happen on a page, policy violations, network errors, deprecations, interventions, and crashes, and delivering them to an endpoint you control. You declare an endpoint with one HTTP header, point a policy at it, and the browser sends structured JSON reports out of band. This documentation is a plain-language standards reference for the whole surface: what the API is, how to set up every reporting header, and what each policy and report type means.

CentralCSP is built on this API. It collects and aggregates every report type at a single endpoint, then turns the stream into client-side security monitoring and PCI DSS v4 evidence, with Content Security Policy (CSP) as the deepest use case.

What the Reporting API is

It helps to separate two roles. A policy or platform feature is the producer of a report: Content Security Policy, Cross-Origin-Opener-Policy, Network Error Logging, a deprecation warning, a crash. The Reporting API is the shared transport underneath them: a queue in the browser that collects those reports and delivers them. The producer decides what is worth reporting; the API decides how it travels.

Three terms run through this reference. A report is a single JSON object describing one event (one CSP violation, one network failure). An endpoint is a URL you control that receives reports, named in a header. A policy is a set of rules the browser enforces, configured by a response header, that can name an endpoint to report to. The API itself defines no policy behavior; it only structures, queues, and delivers what the policies produce.

One expectation to set early: delivery is best-effort, not a guaranteed channel. The specification says so explicitly. Reports can be batched, delayed, deduplicated, or dropped, so treat the stream as a high-value signal, not a complete audit log.

How it works

A policy flags an event. The browser does not send it immediately; it collects the report, batches it with others, and POSTs the batch to the named endpoint as application/reports+json, on its own schedule. Delivery runs independently of the page, which is why a report can still arrive after the page has navigated away or even crashed.

Reporting-Endpoints: csp-endpoint="https://<Endpoint-ID>.report.centralcsp.com"
Content-Security-Policy: default-src 'self'; report-to csp-endpoint

What you can do with it

CentralCSP collects all of these at one endpoint and turns them into alerts and evidence.

In this reference

Get started

The shortest path is to declare one endpoint and confirm a first report arrives. See Get started. To check whether a live site is wired up correctly, use the Reporting API configuration checker.

Sources

On this page