Content Security Policy is the browser instruction that says where a page may load scripts, styles, images, and other resources from, and it is one of the strongest defences against cross-site scripting: even if an attacker injects markup, the browser refuses to load their script from an unlisted source. Writing a policy by hand means juggling directive names, quoted keywords such as self, and source lists, where one typo can break a site or silently weaken it. This builder assembles a correct header from your directive sources, ready to paste into a server configuration or meta tag, with the common directives covered.
Quick Answer: Enter allowed sources for each directive and click Build CSP Header.
Free Online Tool
Content Security Policy Builder
Build a Content-Security-Policy header from directive selections.
How to Use the Content Security Policy Builder
- Enter the sources allowed by default-src, or leave it as self.
- Enter script sources, such as self and any trusted CDN.
- Enter style, image, and font sources the same way.
- Tick upgrade-insecure-requests if your site should force HTTPS.
- Click Build CSP Header.
- Paste the header into your server config and test the site thoroughly before enforcing it.
Key Features
- Covers default-src, script-src, style-src, img-src, font-src, and connect-src.
- Preserves quoted keywords such as self, none, and unsafe-inline exactly.
- Omits directives you leave blank, keeping the header clean.
- Supports upgrade-insecure-requests and block-all-mixed-content flags.
- Produces a single paste-ready header value.
- Runs entirely in the browser; nothing is deployed automatically.
What the Result Means
Each directive is a rule for one resource type: script-src governs scripts, img-src governs images, and default-src is the fallback for any directive you do not list. A source of self means only the same origin, none means nothing at all, and a full URL adds a trusted third party. If a resource stops loading after you deploy, the browser console names the directive that blocked it, which tells you exactly which source to add. A policy that is too loose, especially one with unsafe-inline for scripts, gives up most of the protection, so treat that keyword as a last resort.
Worked Example
A blog loads scripts from itself and one analytics CDN, styles from itself, and images from itself and an image host. Entering those sources produces: default-src self; script-src self https://cdn.example.com; style-src self; img-src self https://images.example.com. Deploying that header blocks any injected script from an unknown host while leaving the legitimate content untouched, and the first console violation after deployment points straight at any source that was missed. If a marketing script is added later, its domain must be added to script-src before launch, or the script will be blocked on the live site while working fine in development where no policy is set.
Best Practices and Tips
- Start in report-only mode to collect violations before enforcing a policy.
- Keep script-src as tight as possible; it is the directive that matters most.
- Add each third-party domain you actually use, including analytics and fonts.
- Use the browser console violation reports to find missing sources after deployment.
- Review the policy after adding any new widget or embed, since each adds sources.
Common Mistakes to Avoid
- Adding unsafe-inline to script-src to fix a breakage, which defeats the policy.
- Forgetting default-src, so unlisted directives fall back to nothing.
- Listing a domain without its scheme and wondering why subdomains are blocked.
- Deploying without testing, then discovering the breakage from users.
Frequently Asked Questions
What does self mean?
It allows resources from the same origin as the page: same scheme, host, and port.
What happens when a resource is blocked?
The browser refuses to load it and logs a violation in the console; the page otherwise keeps working.
Should I use unsafe-inline?
Avoid it for scripts. It allows inline scripts, which is exactly what an injection attack uses.
Where do I deploy the header?
As an HTTP response header from your server, or as a meta tag, though headers are preferred.