--- title: "CSP generator: build a strict policy from real traffic" description: "Build a strict Content Security Policy from real browser reports, not a one-page crawl. Prune extension noise, then move from report-only to enforced safely." url: "https://centralcsp.com/en/platform/csp-builder/" lang: "en" --- 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. [Start free trial](https://app.centralcsp.com) [Scan your current policy](https://centralcsp.com/en/tools/csp-scanner/) - 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. 1. 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. 2. 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'. 3. 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. Comparison of ways to produce a Content Security Policy | | 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](https://centralcsp.com/en/tools/extension/). 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 [See alerting](https://centralcsp.com/en/platform/alerting/) 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 [See monitoring](https://centralcsp.com/en/platform/monitoring/) 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. Scan my site Free, no account needed. Results land on a shareable page. [Build a policy in your browser with the extension](https://centralcsp.com/en/tools/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. - [How to use the CSP Builder](https://centralcsp.com/en/blog/how-to-use-csp-builder) - [The Content-Security-Policy-Report-Only header](https://centralcsp.com/en/docs/web-security/policies/content-security-policy/report-only) - [The Reporting-Endpoints header](https://centralcsp.com/en/docs/web-security/reporting-api/headers/reporting-endpoints) - [Why unsafe-inline defeats your CSP](https://centralcsp.com/en/blog/unsafe-inline-csp) - [Reading CSP violation reports](https://centralcsp.com/en/docs/platform/monitoring/csp) - [Set the CSP header in nginx, Next.js and more](https://centralcsp.com/en/blog/set-csp-header-every-framework) FAQ ## Frequently asked questions Building a policy, filtering noise and rolling it out, answered. ### Can you really build a Content Security Policy from real traffic? Yes, and it is the point. You deploy a report-only policy once, and every browser that visits reports the scripts, styles and connections your pages load. CentralCSP aggregates those reports into a policy that covers your whole site, including the pages and third parties a one-page crawler never reaches. ### Will a generated CSP break my site when I turn it on? Not the way we roll it out. The policy runs in report-only first, which reports violations but blocks nothing, so you see exactly what enforcing would break before it breaks. You flip to enforcing only once the report-only run is clean, and you can flip back at any time. ### What is report-only mode? A Content Security Policy can be sent in two forms. Content-Security-Policy enforces: the browser blocks anything the policy disallows. Content-Security-Policy-Report-Only only reports the violations and blocks nothing. Report-only is how you test a policy against real traffic safely, and it is where every policy here starts. ### How long should I collect before I enforce? Until the report stream stabilises and your important flows have been walked by real traffic. Checkout, login and admin are the ones that matter: a page nobody visited during the report-only run is a page whose sources you have not seen yet. High-traffic sites usually settle within days; a low-traffic page can take weeks, and a quarterly campaign page will not appear until the campaign runs. There is no deadline, because report-only can stay on indefinitely and keeps reporting the whole time. ### How do you filter out browser-extension noise? Ad blockers, password managers and other extensions inject code into every page, and that code trips your policy. It is the main reason CSP reports feel like noise. CentralCSP ranks every source by how many browsers and pages reported it and flags the injected-by-extension pattern, so a source that showed up once inside one user's browser doesn't get mistaken for a real dependency. ### What happens to my inline scripts? They get flagged, not waved through. The builder will not add 'unsafe-inline' to make a report go away, because that single keyword switches off most of what a script-src directive is protecting you from. An inline script shows up as a finding with two honest fixes: move it into an external file, which is the durable answer, or allow that exact script with a hash or a nonce. The hash is a fingerprint of the script's exact bytes, so it stops working the moment the content changes, which is the point. ### How is this different from a free CSP generator that scans my URL? A scanner loads one page in a headless browser and writes a policy for what it happened to see. It misses anything behind a login, a click or an A/B test, and the third-party widget that only loads for some visitors. A policy built from real traffic covers all of it, because the reports come from real users on every page they actually opened. ### Do I need an existing CSP to start? No. You start from a strict report-only base (default-src 'none'), collect for as long as your traffic needs, and let the builder fill the directives from what real browsers report. If you already run a CSP, point its report-to at the same endpoint and CentralCSP builds on what you have. ### Does the policy stay current as my site changes? Reports keep arriving, so the builder keeps showing drift: a new script, a new origin, a source that stopped appearing. You tighten the policy when something legitimate is added and get alerted when something you never approved shows up, instead of rewriting the header by hand every release. ## 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. [Start free trial](https://app.centralcsp.com) [Evaluate a policy for free](https://centralcsp.com/en/tools/csp-evaluator/) --- Available in: [en](https://centralcsp.com/en/platform/csp-builder/), [fr](https://centralcsp.com/fr/platform/csp-builder/)