Content Security Policy Builder
Build a CSP from the origins a page actually loads, in report-only form so it cannot break anything yet.
About this tool
Reads a page, collects every origin it loads from, and writes a Content Security Policy that permits exactly those.
**A policy written from a template is useless in both directions.** Too strict and it blocks the site's own scripts; too loose and it permits everything, which is the same as having none. The only way to write one that is both restrictive and correct is from what the page actually loads, which is what this does.
**The output is report-only, deliberately.** A CSP that blocks something the page needs breaks it silently — no error the visitor sees, just a feature that stopped working. Run in report-only mode for a week, read the reports, then switch the header name to enforce.
**What this cannot see:** anything a script loads after the page runs. A tag manager is one entry in the HTML and a dozen origins once it executes, and none of those appear here. The report-only period is what finds them.
Common questions
Why report-only?
Because a wrong policy breaks the page with no visible error. Report-only sends violation reports and blocks nothing, so you find out what you missed without any visitor finding out first.
Why does it include unsafe-inline?
Only if the page has inline scripts or styles, and it says so. unsafe-inline defeats most of the protection CSP offers — the proper fix is a nonce or a hash per block, which needs a change to how the page is generated.
Do I need a separate policy per page?
Usually one policy covering every origin any page uses. Build from a few representative pages and take the union. A checkout page with a payment provider will need entries the homepage does not.
Does a CSP help SEO?
No, and a wrong one hurts it — a policy blocking your own scripts produces a page that renders incompletely for a crawler exactly as it does for a visitor. That is the reason to be careful, not a reason to skip it.