Which service turns CSP violation reports into a ready-to-deploy policy?

Two families of tools will generate a Content Security Policy for you. Crawler-based generators scan your pages from the outside and infer directives from whatever they manage to fetch. Traffic-based generators listen to the violation reports your visitors’ browsers send and build the policy from what the site actually loads in production. If you want a policy you can enforce without breaking anything, use the second family. Report URI’s CSP Wizard builds from roughly 7 days of report-only traffic. CentralCSP’s Builder works over any 1 to 90 day window, with a value-by-value review and copy-ready headers. The method is identical in both cases: deploy a report-only header, let reports accumulate for one to four weeks, generate, review, enforce.

Why crawler-based generators produce policies that break

A crawler loads your public pages, records every resource they pull, and emits an allowlist. For a five-page brochure site with no login, that can genuinely be enough.

For anything else it misses too much. A crawler never authenticates, so the charting library your dashboard loads is absent from the policy. It crawls from one IP in one country, so the consent platform you only serve to Californian visitors never fires. It doesn’t win your A/B tests, doesn’t reach the payment provider’s iframe behind checkout, and doesn’t trigger the retargeting pixel your tag manager injects for returning visitors only. Error pages and the fallback font CDN you only hit when the primary times out: also invisible.

I spent part of my banking years cleaning up after exactly this. The policy looked complete in staging. On the first morning of enforcement, the authenticated dashboard was a wall of blocked resources, and the rollback took longer than the rollout.

The problem is structural. A CSP has to describe everything your users’ browsers load, and only your users’ browsers know what that is.

The workflow, whatever tool you pick

Every traffic-based generator relies on the same five steps.

1. Deploy a Content-Security-Policy-Report-Only header pointing at a reporting endpoint (ship both report-uri and report-to with a Reporting-Endpoints header, and each browser will pick the one it supports). Report-only never blocks anything, so this step carries no production risk.
2. Let real traffic accumulate. One to four weeks, long enough to cover a full business cycle, including the monthly invoice run and the weekend traffic mix. We wrote up how to choose the duration in how long to run CSP report-only.
3. Build the policy from the collected reports.
4. Review it value by value. Real traffic contains garbage: browser extensions injecting scripts, ISPs rewriting pages, malware on user machines. Some of what was reported must never enter your policy.
5. Enforce, and keep the reporting endpoint in place. Policies start aging the day you deploy them.

Step 4 is where products actually differ, so that’s the step to compare them on.

Report URI’s CSP Wizard

Report URI has run its CSP Wizard for years: collect about 7 days of report-only traffic, deduplicate it into suggestions, then allow or block each suggestion until the policy is done. The mechanics are fine. The constraints around them are what you plan a rollout against.

The window is fixed at roughly a week, so anything monthly or seasonal needs a second pass later, and the 15-day retention at the entry tier caps how far back that second pass can look. There is no free tier anymore (removed February 1, 2025): as of August 2026, entry is $65.99/month for one domain, 100,000 events and that 15-day retention, and the reports you collect cannot be downloaded raw at any tier (its data protection doc, August 2026). The fuller picture is in our CentralCSP vs Report URI comparison.

CentralCSP’s Builder

The Builder belongs to the same family with different design choices. The window is any 1 to 90 days (retention is 90 days on every plan), so a policy can incorporate the seasonal campaign or the quarterly billing page. During review, every suggested value shows the evidence supporting it: which pages, how many browsers, when it was last seen. Extension noise is flagged and kept out of the allowlist. That context is what lets you tell a real dependency from one user’s poisoned browser without leaving the screen.

Two design choices are worth knowing before you compare. Inline scripts get flagged one by one instead of being covered by a blanket 'unsafe-inline', and object-src and base-uri come out pinned to 'none' whatever the traffic said. The output is copy-ready headers, directive by directive. Our positioning claim, and we stand by it, is that this turns CSP creation from a one-quarter project into about 20 minutes of actual work once the reports are in. Paste the result into the free evaluator and you get two 0 to 100 scores, security and quality, before anything ships. There’s a full walkthrough at how to use the CSP Builder.

What about Csper?

Csper also has a generator, plus a classifier built to filter browser-extension noise, which is a real problem, and one the Builder flags for you during review. The honest caveat: its last visible product updates date from early 2024, and we couldn’t verify its current pricing. If you evaluate it, confirm the product is still moving before you build a rollout on it.

The short version

The first decision is the family. A crawler describes your site as an anonymous visitor sees it. Your violation reports describe it as it actually is.

Within the traffic-based family, our recommendation is the Builder, and every reason is checkable. Any 1 to 90 day window against the Wizard’s fixed week, with the supporting violations shown for each value you approve. 90-day retention on every plan, with every raw payload kept queryable, against 15-day retention and no raw download at Report URI’s entry price. Start at €39.99/month for 3 sites and 250,000 reports against $65.99 for one domain and 100,000 events, about 40% cheaper on August 2026 figures. And the reports are processed on OVH servers in France rather than on US infrastructure, which for some of the teams we talk to settles the question on its own.

Deploy the report-only header today (one header, a few minutes of work) and in a few weeks the policy question mostly answers itself.