--- title: "CSP violation monitoring and 12 browser report types" description: "One endpoint collects all 12 browser report types: CSP violations, script hashes, NEL, crashes. Deduped, classified, EU-hosted." url: "https://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.centralcsp.com) [Check what your site collects](https://centralcsp.com/en/tools/reporting-api/) How it works ## From response header to alerts in your existing channels. A reporting endpoint is a URL the browser POSTs its reports to, named in a Reporting-Endpoints response header. CSP violation monitoring is collecting those reports from real traffic, deduplicating them and reading them, whether your policy runs in report-only or enforced. 1. 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 ## Your reporting endpoint is one response header away. Add Reporting-Endpoints to your responses and browsers start delivering their reports 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. Legacy report-uri payloads are accepted as well, so switching collectors is the same one-line change. 1. ### Add your site Create the site in your dashboard and copy its managed reporting endpoint. 2. ### Ship the header Deploy from your edge or app. Reports flow from real visitor browsers immediately. 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. - See the trend, spot the change - Aggregated: one issue, one row 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://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://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://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://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 (NEL) DNS failures, TLS errors and dropped connections, logged by the browser that experienced them. Network Error Logging takes its own NEL header and a Report-To group, and is Chromium-only today. [View docs](https://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://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://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://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://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://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://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://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, landing in France on OVH and never leaving the EU. 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.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://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 workspace API keys - CSV and raw-report exports - Built-in MCP server [See the API](https://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://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://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://centralcsp.com/en/platform/supply-chain/) Further reading ## Read the reference before you wire it up How the Reporting API works, which header to send, and what happens to a report once it lands. - [How the Reporting API works](https://centralcsp.com/en/docs/web-security/reporting-api/concepts/how-the-reporting-api-works) - [The Reporting-Endpoints header](https://centralcsp.com/en/docs/web-security/reporting-api/headers/reporting-endpoints) - [Connect your site step by step](https://centralcsp.com/en/docs/platform/websites/connect-your-site) - [Read the monitoring guide](https://centralcsp.com/en/docs/platform/monitoring) - [How long reports are kept](https://centralcsp.com/en/docs/platform/security/data-retention) - [Where browser CSP reports go, and build vs buy](https://centralcsp.com/en/blog/where-to-send-csp-reports) 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. ### How long are reports stored? Browser reports are kept for 90 days. That window is fixed and not configurable. The decisions you make on top of them, such as script justifications and audit log entries, are kept until the account is deleted, because those are the records an assessment asks for rather than raw telemetry. ### 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 and intervention reports only need the Reporting-Endpoints header. Network errors are the exception: they take their own NEL header plus a Report-To group. For CSP, you can start with Content-Security-Policy-Report-Only, which reports everything and blocks nothing. ### Can I just build my own report collector? Yes. An endpoint is a URL that accepts POST with application/reports+json, and application/csp-report for the legacy report-uri format, and returns a 2xx. The endpoint is the easy part. What follows is volume, because a busy site generates far more reports than page views on the day a policy is wrong; deduplication, because the same violation arrives thousands of times; browser-extension noise, which is the majority of what an open endpoint receives; and storage you have to keep queryable. CentralCSP is those four, not the URL. ### What happens on a violation spike, or when a site hits its report quota? Each website carries its own cap, so one misconfigured site cannot drain the workspace quota on its own. Ingestion filters let you restrict which origins are allowed to report, which is how you keep an open endpoint from absorbing traffic that is not yours. You get usage warnings at 80% and 100% of the workspace quota by email, and ingestion stops at the limit rather than billing past it. ## 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.centralcsp.com) [Check your reporting setup](https://centralcsp.com/en/tools/reporting-api/) --- Available in: [en](https://centralcsp.com/en/platform/monitoring/), [fr](https://centralcsp.com/fr/platform/monitoring/)