CSP builder
The strictest CSP your site can run, built from real traffic.
A strict Content Security Policy is your best defense against cross-site scripting, and the hardest header to write by hand. CentralCSP builds yours from what real browsers report, not from a crawler's snapshot of your homepage.
From real traffic
Not a crawler snapshot
One response header
No agent, no page script
Collected in the EU
France, kept 90 days
Report-only first
Enforce when it's clean
Directive by directive
Every source justified
How the CSP generator works
From real reports to a policy you can enforce.
A CSP builder turns the violation reports browsers already send into a Content Security Policy. Instead of loading one page in a headless browser, it aggregates what every visitor's browser reported across every page they opened, then proposes a policy directive by directive. No crawl, no guesswork, no allowlist typed from memory.
01 - Collect
Real browsers report every source
Ship the report-only policy we generate for you. It blocks nothing, and from that moment every visitor's browser reports each script, style and connection your pages actually load.
02 - Build
We draft the policy, directive by directive
CentralCSP turns those reports into a Content Security Policy: script-src, style-src, connect-src, img-src, font-src and frame-src, each filled with the exact sources your real traffic justifies and nothing it doesn't, with object-src and base-uri pinned to 'none'.
03 - Deploy
Deploy the policy you built
When the report-only run is clean, copy the finished header and set it wherever you already set headers: an nginx or Apache config, a CDN edge worker, or a framework middleware. Serve it as enforcing and the browser blocks everything the policy doesn't allow.
You approve the policy before it ships.
Every source the builder proposes carries its evidence: how many browsers loaded it, on which pages, and when it was last seen. A real dependency is obvious, and the junk that ad blockers and password managers inject gets flagged as extension noise so it never lands in your allowlist. Keep what's real, drop the rest, one directive at a time.
- Each source ranked by report volume
- Browser-extension noise flagged for you
- Keep or drop, directive by directive
It ships strict, not just working.
A crawler emits a loose allowlist that happens to load your page. A report-driven policy locks script-src to the exact hosts your traffic uses, closes connect-src to the origins you actually talk to, and sets object-src and base-uri to none. Where an inline script would force unsafe-inline, the builder flags it instead of quietly weakening the policy, so an attacker gets no XSS foothold from a loophole you never noticed.
- script-src limited to the hosts you actually load
- connect-src, object-src and base-uri locked down
- Inline scripts flagged, never silently allowed
Approaches
Three ways to get a Content Security Policy.
A CSP is only as good as its coverage. Here is the honest comparison between writing one by hand, scanning a page for one, and building it from the traffic you already have.
| CentralCSP | Crawler / scanner | By hand | |
|---|---|---|---|
| Covers pages behind a login | Every visited page | Homepage only | If you remember it |
| Sees conditional third parties | Real sessions catch them | Missed if not triggered | Only what you know |
| Filters browser-extension noise | Flagged by volume | Not distinguished | You guess |
| Stays current as the site changes | New reports show drift | A one-time snapshot | Manual rewrite |
| Reaches enforcement safely | Report-only, then enforce | Starter policy only | Days of testing |
There is a fourth way: inject a report-only policy locally with a browser extension and build from what that one browser sees. It is genuinely good for authoring and debugging a single page, and our Chrome extension does exactly that, free. Whole-site coverage still needs real traffic, because one browser on one page is not your site.
Alerting
A new source shows up? You hear about it.
The same reports that build your policy can page you. When a script loads from an origin your policy never allowed, CentralCSP posts it to Slack, Teams, Google Chat, Telegram or email before the next visitor loads the page.
- New-origin and hash-change rules
- Violation spikes after a deploy
- Routed to the channel that owns the page
'%20gradientUnits='userSpaceOnUse'%3e%3cstop%20offset='0'%20style='stop-color:%235a62c3'/%3e%3cstop%20offset='.5'%20style='stop-color:%234d55bd'/%3e%3cstop%20offset='1'%20style='stop-color:%233940ab'/%3e%3c/linearGradient%3e%3cpath%20d='M21.8%20125h218.3c12.1%200%2021.8%209.8%2021.8%2021.8v218.3c0%2012.1-9.8%2021.8-21.8%2021.8H21.8C9.8%20387%200%20377.2%200%20365.2V146.8c0-12%209.8-21.8%2021.8-21.8'%20style='fill:url(%23microsoft-teams_svg__SVGID_1_)'/%3e%3cpath%20d='M188.4%20208.1h-43.6v118.8H117V208.1H73.5V185h114.9z'%20style='fill:%23fff'/%3e%3c/svg%3e)
Monitoring
CSP is one report. Browsers send eleven more.
Your policy only reports what it blocks. Real browsers also report network errors, crashed tabs, deprecations and integrity failures, and CentralCSP collects all twelve types on the same endpoint, deduped and classified.
- All 12 browser report types, one endpoint
- Deduped, grouped and searchable
- Server-side failures the browser sees first
Check your headers
What does your site send today?
Two minutes, no account: scan your live headers and see whether you have a Content Security Policy at all, how strict it is, and which origins can run code on your pages right now.
Free, no account needed. Results land on a shareable page. Build a policy in your browser with the extension.
Further reading
How a policy gets built, in detail
Report-only, the endpoint header, and shipping the finished policy on whatever stack you run.
FAQ
Frequently asked questions
Building a policy, filtering noise and rolling it out, answered.
Start collecting today. Enforce when you're ready.
Ship one report-only header this afternoon and watch the policy draft itself from your real traffic. 14-day free trial, no agent, no page script.
