--- title: "CSP violation & browser report monitoring" description: "Collect all 12 browser report types from one header: CSP violations, script hashes, network errors, crashes. Deduped, classified, EU-hosted." url: "https://next.centralcsp.com/en/platform/monitoring/" lang: "en" --- Monitoring # All browser signals, in one place. Blocked scripts, failed connections, crashed tabs: browsers report them as real users browse. CentralCSP collects all of it with one response header. [Start free trial](https://app.next.centralcsp.com) [Check what your site collects](https://next.centralcsp.com/en/tools/reporting-api/) How it works ## From response header to alerts in your existing channels. The pipeline between a visitor's browser and your team, end to end. 1. MyEndpoint.report.centralcsp.com 01 - Collect ### Ship one header Add Reporting-Endpoints at your CDN, proxy or framework. Legacy report-uri lands on the same endpoint. 2. 02 - Process ### Collected, deduped, classified Browsers send reports in the background: visitors feel nothing. Every report is kept; duplicates group together and extension false positives get flagged. 3. 03 - Act ### Watch, alert, export Filter the live feed, route alerts to your channels, pull the raw JSON over the API. Setup ## The whole setup is one header. Add Reporting-Endpoints to your responses and browsers start delivering every report type to your endpoint. response header Reporting-Endpoints : default= "https://MyEndpoint.report.centralcsp.com" Have a CSP already? Point its report-to at the same endpoint and every violation lands there too. 1. 1 Add your site Create the site in your dashboard and copy its managed reporting endpoint. 2. 2 Ship the header Deploy from your edge or app. Reports flow from real visitor browsers immediately. 3. 3 Route the signal Watch the live dashboard, wire alerts to your channels, pull anything over the API. Verify your setup ## Is your site already reporting? Verify my config Free, no account needed. Results land on a shareable page. The scan verifies - Policy setup: which report types your headers request - Endpoint setup: where reports are sent and if it responds - Misconfigurations: what silently gets dropped today Aggregation ## A million reports become a short list of issues. Raw reports stay stored and queryable, but you work from the aggregate: grouped, deduped and ranked so the real problem surfaces first. - Duplicates collapse into one issue - Grouped by directive, origin and page - Trends and spikes over time - Extension noise flagged for you What we collect ## Twelve report types. Three reasons to want them. Most tools stop at CSP violations. Browsers can report much more, and every type below lands on the same endpoint, parsed and searchable. ### Attack signals The reports that catch injected code, tampered files and data leaving the page. `csp-violation` CSP violations A resource loaded, or tried to, against your Content Security Policy. Works enforced or report-only. [View docs](https://next.centralcsp.com/en/docs/web-security/reporting-api/reports/csp-violation) `csp-hash` Script hashes The hash of every script your pages execute. Your script inventory, and your PCI DSS 6.4.3 evidence, sourced from real traffic. [View docs](https://next.centralcsp.com/en/docs/web-security/reporting-api/reports/csp-hash) `integrity-violation` Integrity violations A file no longer matches its Subresource Integrity hash. Either your build changed it, or someone else did. [View docs](https://next.centralcsp.com/en/docs/web-security/reporting-api/reports/integrity-violation) `connection-allowlist` Connection Allowlist violations An outbound connection left the page for an origin you never declared. This is how exfiltration gets noticed. [View docs](https://next.centralcsp.com/en/docs/web-security/reporting-api/reports/connection-allowlist) ### Failures your server never logs These happen before the request reaches you, or after the page is dead. Only the browser can report them. `network-error` Network errors DNS failures, TLS errors and dropped connections, logged by the browser that experienced them. [View docs](https://next.centralcsp.com/en/docs/web-security/reporting-api/reports/network-error) `crash` Crashes The tab crashed or ran out of memory. A dead page can't run a monitoring script; the Reporting API is the only witness. [View docs](https://next.centralcsp.com/en/docs/web-security/reporting-api/reports/crash) `deprecation` Deprecations Your pages call an API the browser plans to remove, with the removal date when the browser knows it. [View docs](https://next.centralcsp.com/en/docs/web-security/reporting-api/reports/deprecation) `intervention` Interventions The browser changed your page's behavior on its own: an autoplay denied, a slow script throttled. [View docs](https://next.centralcsp.com/en/docs/web-security/reporting-api/reports/intervention) ### Policy hygiene Proof that the isolation and permission policies you ship actually hold in production. `permissions-policy-violation` Permissions Policy violations Code asked for camera, geolocation or another gated feature against your Permissions-Policy. [View docs](https://next.centralcsp.com/en/docs/web-security/reporting-api/reports/permissions-policy-violation) `document-policy-violation` Document Policy violations A page behavior broke the configuration your Document-Policy declares. [View docs](https://next.centralcsp.com/en/docs/web-security/reporting-api/reports/document-policy-violation) `coop` COOP violations A cross-origin window interaction your Cross-Origin-Opener-Policy blocked or would block. [View docs](https://next.centralcsp.com/en/docs/web-security/reporting-api/reports/coop) `coep` COEP violations A resource loaded without the opt-in your Cross-Origin-Embedder-Policy requires. [View docs](https://next.centralcsp.com/en/docs/web-security/reporting-api/reports/coep) Coverage ## Reports from every visitor, everywhere. Your monitoring runs wherever your users are: every browser, every network, every country your traffic comes from. ### Full Reporting-API support All 12 report types over both header generations, on one endpoint. If a browser can send it, we collect it. ### Real-time signal Reports hit your feed moments after the browser sends them, already deduped and classified. Alert rules fire as it happens. ### Built for scale 1.5 billion reports ingested and counting. A violation spike on your busiest day is when the feed matters most, so it never falls behind. After collection ## Collection is half the job. What the platform does with the reports once they're parsed. ### Live dashboard Filter the feed by report type, directive, browser or origin, and drill into any report's raw JSON. - Feed filtered by type, directive, browser, origin - Raw JSON for every report - Per-site scores and inventories [Open the dashboard](https://app.next.centralcsp.com) ### Alert rules New origin, hash change, violation spike: route what matters to the channels your team already uses. - New-origin and hash-change rules - Violation spike detection - Slack, Teams, Google Chat, Telegram, email [See alerting](https://next.centralcsp.com/en/platform/alerting/) ### API and MCP Everything in the feed is queryable over the REST API, exportable as CSV, and drivable by AI agents over MCP. - REST API with scoped tokens - CSV and raw-report exports - Built-in MCP server [See the API](https://next.centralcsp.com/en/platform/api-mcp/) ### CSP builder Turn the collected violations into a Content Security Policy that fits your real traffic, then tighten it over time. - Policy built from production reports - Directive-by-directive suggestions - Test in report-only first [See the CSP builder](https://next.centralcsp.com/en/platform/csp-builder/) ### PCI DSS evidence The same reports feed a continuous script inventory of your payment pages, exported as auditor-ready evidence. - Requirements 6.4.3 and 11.6.1 - Continuous script inventory - Auditor-ready exports [See PCI DSS](https://next.centralcsp.com/en/platform/pci-dss/) ### Supply chain Every script in your inventory is checked against known CVEs, so a compromised dependency doesn't stay quiet. - Known CVEs flagged in your scripts - New-script detection - Fed by the same reports [See supply chain](https://next.centralcsp.com/en/platform/supply-chain/) FAQ ## Frequently asked questions Performance, privacy and browser support, answered. ### Does collecting reports slow my site down? No. There is no script to load: the browser generates reports itself and sends them in batches, out of band, up to a minute after the page loads. Your pages ship the same bytes as before, plus one response header. ### Do browser reports contain personal data? The payload contains URLs, directives, source locations and the browser family; it does not contain cookies, form input or session identity. URLs can still carry personal data in their query parameters (an email or a token in a query string, for example), so CentralCSP offers an option to strip query parameters from collected reports before anything is stored. Reports are stored in France, on OVH, and never leave the EU. ### Which browsers send reports? Effectively all of them. Modern browsers report through the Reporting API; older ones still send CSP violations through the legacy report-uri directive. CentralCSP accepts both formats on the same endpoint, so every browser in your traffic reports. ### What's the difference between report-uri, report-to and Reporting-Endpoints? They are three generations of the same idea: report-uri is the legacy CSP directive, Report-To came with the first Reporting API, and Reporting-Endpoints is the current header. Ship Reporting-Endpoints plus report-uri and every generation is covered; both deliver to the same CentralCSP endpoint. ### Why do CSP reports include violations that aren't real? Browser extensions like ad blockers and password managers inject code into every page, and that code trips your policy. It's the main source of CSP noise. CentralCSP collects those reports too, and flags them as extension noise so you can tell at a glance what matters on your site. ### Do I need a Content Security Policy before I can monitor? No. Crash, deprecation, intervention and network-error reports only need the Reporting-Endpoints header. For CSP, you can start with Content-Security-Policy-Report-Only, which reports everything and blocks nothing. ## Your next visitor can be your first report. Add the header, watch the feed fill up with real traffic. 14-day free trial, no agent to deploy. [Start free trial](https://app.next.centralcsp.com) [Check your reporting setup](https://next.centralcsp.com/en/tools/reporting-api/) --- Available in: [en](https://next.centralcsp.com/en/platform/monitoring/), [fr](https://next.centralcsp.com/fr/platform/monitoring/)