Report URI alternatives, CSP reporting tools compared

Report URI collects CSP reports, and that is where it stops. If you need a real script inventory, alerting that reaches the team, PCI DSS evidence, and an interface people actually open, you need a client-side security platform rather than a collector. We build CentralCSP, so read this as our view. This post lists what to look for, measures CentralCSP against it, then covers Report URI, URIports, csper, and Sentry briefly, with a table and a migration path.

To see it on your own traffic, start a free trial, add one header, and the monitoring overview shows each report type as it lands.

What a security team needs from a CSP reporting tool

Every tool on this page receives a violation report. The difference is what happens next, and six criteria separate a collector from a client-side security platform.

A path to enforcement. Reports grouped by directive and origin, extension noise filtered out, and the policy tracked over time, so a report-only rollout ends in an enforced header rather than an unread log.
Script inventory and PCI DSS evidence. CSP hash reporting ('report-sha256' and the csp-hash report) tells you which scripts actually ran on each page. A security tool turns that into an inventory with authorization decisions and exportable evidence for PCI DSS v4 requirements 6.4.3 and 11.6.1. It should also tell you which library and version each script is, and whether a known CVE applies.
Alerting where the team works. A new script on the checkout page should reach Slack, Teams, or a webhook within minutes.
EU hosting and fixed retention. Reports carry page URLs, blocked URLs, and script samples, so where they live and for how long is a data-protection question.
API and MCP access. A REST API for your own tooling, and an MCP server so an AI assistant can query violations and the inventory directly.
Rating-finding remediation. BitSight, SecurityScorecard, and RiskRecon score your CSP and security headers from the outside. The tool should scan what your server sends and drive the fix, not only receive what the browser reports.

CentralCSP

CentralCSP is a client-side security platform built on the browser Reporting API. You connect a site with one Reporting-Endpoints header (plus Report-To for Network Error Logging, which only delivers through the legacy header). No agent, no proxy, no JavaScript snippet. The browser keeps enforcing; CentralCSP turns what it reports into decisions.

Against the six criteria:

Enforcement path. Violations are grouped by directive and origin, extension noise is set aside, and the policy is tracked from report-only to enforce. The same endpoint ingests the 12 browser report types (CSP violations, CSP hashes, NEL, deprecation, intervention, crash, COOP, COEP, Permissions-Policy, Document-Policy, Integrity-Policy, and Connection-Allowlist). CSP has the deepest feature set; the other types are ingested and displayed today, with deeper features on the roadmap.
Script inventory and PCI DSS. Hash reporting builds a script inventory of what runs on each page, and the PCI DSS module turns it into review decisions and an exportable evidence pack. CentralCSP helps you meet requirements 6.4.3 and 11.6.1; your assessor signs off. The technologies inventory names the library and version behind each script and flags known CVEs.
Alerting. Slack, Microsoft Teams, Google Chat, Telegram, email, and webhooks.
EU hosting. Report and customer data are hosted in Europe, on OVH, with a fixed 90-day retention. The platform is independently penetration tested and supports SSO, RBAC, MFA, and an audit log. Stripe handles payments from the US, so the residency claim is scoped to report and customer data.
API and MCP. The REST API and the built-in MCP server expose the same data to scripts and AI clients.
Rating findings. The free CSP scanner, security headers scanner, and Reporting API checker read what your server sends today; the dashboard then carries the fix through to the enforced header a rating agency scores.

It is built for enterprises with a security team and for smaller businesses that take client-side security seriously. Plan details live on the pricing page.

Report URI

Report URI is the older, collection-first generation of CSP reporting tools. It accepts CSP violations, NEL, and the other Reporting API report types, and it stores them. That is the whole model: it keeps a script list rather than a review workflow with written justifications, alerting covers the events the service documents, and the interface is organised around report volumes rather than around decisions. Pricing is per domain, and what security features exist sit in the upper tiers. It still fits a single domain with nobody accountable for client-side risk.

URIports, csper, Sentry, and self-hosting

URIports is a Dutch service that grew out of DMARC reporting. It is EU-hosted, accepts the browser report types, and alerts by email, webhook, and Telegram. There is no script inventory, no PCI DSS evidence, and no MCP server. It fits when email authentication is half of your problem.

csper is a developer tool built around CSP only, with a policy generator, an evaluator, a browser extension, and reports classified by type. It does not cover the other Reporting API types and has no script inventory or PCI DSS evidence. It suits an independent developer who wants to try CSP on a personal project.

Sentry can receive CSP violations as events next to your JavaScript errors if you already run it. There is no CSP-specific grouping across a site, no inventory, and no other report types. Fine for an application team; not a replacement for a dedicated endpoint once security or compliance owns the reports.

Self-hosting is tempting because accepting the POST is a few lines of code, as the where CSP reports go post shows. Grouping, deduplication, noise filtering, retention, alerting, a UI, and the other payload shapes are the actual cost, and most home-built collectors stop being maintained once their author moves on.

Comparison table

✅ covered, 🟠 partial, ❌ not offered, per each vendor's public documentation in September 2026.

	CentralCSP	Report URI	URIports	csper	Sentry
CSP reports	✅	✅	✅	✅	✅
Other report types	✅	✅	✅	❌	❌
NEL	✅	✅	✅	❌	❌
Script inventory	✅ Full	🟠 List only	❌	❌	❌
Tech and CVE detection	✅	❌	❌	❌	❌
PCI DSS evidence	✅ Full flow	🟠 List only	❌	❌	❌
Alerting	✅ Rules, 6 channels	🟠 Limited	🟠 Email, webhook	🟠 Spike alerts	🟠 Sentry alerts
Header scanning	✅	❌	❌	🟠	❌
REST API	✅ Full	🟠 Read-only	🟠 Limited	✅	✅
MCP server	✅ Full	🟠 Limited	❌	❌	🟠
EU hosting	✅ OVH	🟠	✅	❌	🟠

Product names belong to their owners. The comparison is based on each vendor's public documentation at the time of writing.

How to switch from Report URI

You do not need a cut-over day. A browser that understands report-to ignores report-uri when both are present, so the two endpoints never double-report and you can run both for a week.

Create a website in CentralCSP and copy its endpoint.
Add a Reporting-Endpoints header that names it, and a report-to directive to the policy, keeping the existing report-uri.
Compare the two dashboards for a week; volumes match once grouping and extension filtering are accounted for.
Remove the old report-uri directive and cancel the old subscription.

Reporting-Endpoints: csp-endpoint="https://MyEndpoint.report.centralcsp.com"

Content-Security-Policy:
    default-src 'self';
    script-src 'nonce-{RANDOM}' 'strict-dynamic';
    object-src 'none';
    base-uri 'none';
    report-uri https://old-collector.example/r/d/csp/enforce;
    report-to csp-endpoint

For the other report types, add a default endpoint to the same Reporting-Endpoints header. NEL is the exception and needs a Report-To header; the Report-To vs Reporting-Endpoints page shows both side by side.

Which one to pick

Any tool above will hold CSP reports. If you own client-side security and need a script inventory, PCI DSS evidence, alerting, EU hosting, and an API and MCP server, start a free trial, point report-to at your endpoint, and watch the first reports arrive in the monitoring overview.

Report URI alternatives for CSP reporting