Every way to collect CSP reports, and what each one costs
A Content Security Policy without a report endpoint is a policy nobody can safely enforce. Getting those reports somewhere useful has half a dozen answers, from twenty lines of your own code to a full platform. Here is what each route actually involves once real traffic hits it.
By Scott Helme — CEO and Founder · 24 July 2026, updated 11 August 2026
All of them work in the sense that reports arrive somewhere. They differ in what happens on the day a policy on a busy site produces forty thousand violations, most of which are browser extensions and none of which are labelled as such.
A handler that accepts a POST and writes it somewhere. Genuinely a short piece of code — and then it is a public, unauthenticated endpoint anyone on the internet can post to, with no rate limiting and no deduplication, receiving traffic proportional to your busiest pages.
Reports land in the same place as everything else. Ingestion is billed by volume, and CSP violations are high-volume and highly repetitive, so this is usually cheap in month one and a conversation with finance by month three.
Some error trackers accept CSP reports as a side feature. It works, and violations then compete for attention with application exceptions in a tool built around stack traces rather than around origins, directives and scripts.
Convenient if the whole estate sits behind one provider. Coverage follows that boundary, and both the tooling and its accumulated history move if the provider ever does.
Proxies, agents and scanners typically offer a CSP endpoint alongside their main product. Reporting is a supporting feature there rather than the thing being built, and most of them ask you to add something to your pages.
More common than anyone admits. The policy goes out in report-only mode with nowhere to report to, nobody sees a violation, and the header sits there indefinitely enforcing nothing. It is the most expensive option, because it looks like the job is done.
The do-it-yourself route is the honest comparison, because every other route is a partial version of it. This is the work that sits between a handler that accepts a POST and something a team will still be using in a year.
| What you need | Report URI | Build your own |
|---|---|---|
| Accepting reports | A hosted endpoint with abuse handling and rate limiting | An unauthenticated public endpoint, exposed to anyone |
| Volume | Absorbed. It is what the infrastructure exists to do | Scales with your busiest pages, and with anyone abusing it |
| Extension noise | Filtered out before it reaches you | Most of what arrives, and none of it labelled |
| Deduplication | Grouped and counted, so a spike is one line | One misbehaving script can produce millions of identical rows |
| Writing the policy | Generated from what browsers reported, via CSP Builder | Read the reports and assemble it by hand |
| Knowing a script changed | Scripts fetched, hash-verified, archived and diffable | Not available — reports carry metadata, not code |
| Other report types | Fourteen, through the same endpoint | Each one is another parser and another schema |
| Ongoing cost | A published subscription price that does not move when a script misbehaves | Storage, ingestion and somebody's time, indefinitely |
Nearly every abandoned CSP deployment we hear about failed at the same point, and it was never at collection. The reports arrived perfectly well. Nobody could get from them to a policy they were willing to enforce.
Browser extensions inject scripts and styles into every page they touch, and each injection is a violation your policy dutifully reports. Without filtering, that is what a CSP report feed looks like: a wall of noise from software you do not control, running on machines you do not own, hiding the handful of entries that describe your actual dependencies.
Learn more about CSP Reporting →CSP is the first reporting header most teams deploy and rarely the last. The Reporting API carries network errors, integrity failures, cross-origin isolation problems, deprecations and renderer crashes through the same mechanism. Building for one means building for one; the rest arrive here by adding a directive.
See every report type →One header. No code. Point your existing report-uri directive at us and violations arrive within minutes.
30-day free trial · One header · No code · Cancel anytime
Start in report-only mode. It changes nothing about how your site behaves — the browser reports what a policy would have blocked and blocks nothing — so there is no risk in leaving it running for a week while the reports build a picture of what your pages really load. Only then is enforcement a decision rather than a gamble.