Build a Content-Security-Policy header from directive pickers — protect your site from XSS and injection.
How to use this tool
Strict blocks objects and framing; basic allows images from https: and data:.
Sources are space-separated; use 'self', 'none', data:, https: or a host as needed.
Tick Report-Only to test the policy without breaking the site.
Add it to your server config or meta tag and watch the console for violations.
Formula & worked example
default-src 'self', script-src 'self', img-src 'self' data: gives header Content-Security-Policy: default-src 'self'; script-src 'self'; img-src 'self' data:.
Limitations — read this before you rely on it
This generates the header value only — it does not set it on your server, and it does not scan your site for blocked resources. 'unsafe-inline' and 'unsafe-eval' are never added by presets; add them by hand only if you understand the risk, and prefer nonces or hashes for inline scripts.
Frequently asked questions
Content Security Policy: an HTTP header that tells the browser which sources may load scripts, styles, images and other resources, limiting XSS and injection damage.
Report-Only logs violations without blocking, so you can find what a policy would break before enforcing it.
A policy without 'unsafe-inline' (or a matching nonce/hash) blocks inline scripts and event handlers. Move scripts to files or add nonces.
No. It generates the header text; you add it in your server, CDN or hosting config.
For a simple site, often yes. Third-party analytics, fonts, embeds and payment scripts each need their hosts added explicitly.