HOW TO USE
Configure each CSP directive below. The generated header updates live. Copy the value into your web server config or HTTP response headers.
CSP Header Builder
Builds a Content-Security-Policy header directive by directive, with an explanation of what each one actually restricts, so you end up with something you understand rather than a policy copy-pasted from a Stack Overflow answer that may or may not fit your site. Copy the result straight into your server config.
The directives that matter most
- default-src — the fallback for any resource type not covered by a more specific directive
- script-src — which JavaScript sources the browser will actually execute. Avoid
'unsafe-inline'and'unsafe-eval'in production — they undo most of what CSP is for. - style-src — same idea for CSS. If you're pulling in Google Fonts, that domain needs adding here explicitly.
- object-src 'none' — set this on every site, no exceptions. It blocks legacy Flash/Java plugin content outright, and there's essentially never a legitimate reason not to.
- upgrade-insecure-requests — automatically upgrades any lingering HTTP references to HTTPS
- report-uri — sends violation reports to an endpoint you control, which is how you actually find out what's breaking before you enforce the policy for real
The rollout approach that actually works
Ship the policy as Content-Security-Policy-Report-Only first. It logs every violation without blocking anything, which means you get a real list of legitimate sources your policy needs to allow — a third-party analytics script, a CDN you forgot about, an inline script a previous developer left in — before you flip it to enforcing and risk breaking something in production. Skipping the report-only stage is how CSP rollouts turn into "why is the checkout page broken" incidents.