The CSP Builder

What this tool does

A Content-Security-Policy is a browser-enforced allowlist: it tells the browser which origins a page may load scripts, styles, frames, fonts and images from, and which it may talk to. Done well, it is the control that turns an HTML injection bug into a blocked console message instead of a stolen session. Done the usual way, it is a header someone pasted from a generator, with 'unsafe-inline' in it, that stops nothing and breaks the checkout.

This builder has two modes, and both of them run entirely in your browser.

Build

You answer what your site actually loads — whether you have inline scripts and whether you can add a nonce to them, which third parties you embed, where your API lives, who is allowed to frame you, where your forms post. It assembles the directives from that, including the ones people forget because nothing visibly breaks when they are missing: base-uri, form-action, object-src and frame-ancestors.

Validate

You paste a policy you already have and it tells you what that policy actually permits, directive by directive, in plain English — including the directives that are not written down, because an absent directive either falls back to default-src or is unrestricted, and which of those it is changes the answer completely.

Why it predicts breakage

Most generators hand you a policy and wish you luck. The reason CSPs get rolled back is never the policy nobody can read — it is the font that silently falls back, the analytics that stops reporting with no error on the page, the payment iframe that renders blank. So this names them: for every answer you give, it says what will stop working and why, and it separates that from the directives that are permissive enough to be pointless — 'unsafe-inline' sitting next to a nonce that already overrides it, a wildcard source, a CDN on your allowlist that will serve an attacker any file they ask for.

Report-only first

Every policy it builds comes with its Content-Security-Policy-Report-Only twin. That header enforces nothing and reports everything, so you can ship it beside your real traffic, collect a week of violations from browsers you do not own, and find out what you missed before a customer does. Deploying the enforcing header first is how a CSP becomes an incident.

Nothing leaves your browser

No account, no upload, no server. The policy you paste and the origins you type stay in the page and are gone when you close the tab — there is no save and no resume. It never fetches a URL you enter, so nothing here reaches out to your site or tells us what you are protecting. Our analytics records that the tool was started, finished or copied from, and nothing else: not an origin, not a policy, not a length.

What it is not

It is a reading of the policy text, not of your site. It cannot see a javascript: URL in your markup, a JSONP endpoint on a host you have allowlisted, or a script your tag manager injects at runtime — so a clean result here means the policy is coherent, not that it holds. The report-only run is what checks that. The allowlist-bypass warnings draw on the CSP-bypass research by Lukas Weichselbaum and colleagues at Google (CSP Is Dead, Long Live CSP, CCS 2016), which is also the work that made 'strict-dynamic' exist.