Content Security Policy (CSP) Builder

CSP headers are powerful but fiddly to write correctly. This builder lets you toggle each directive (script-src, style-src, img-src, etc.), pick allowed sources ("self", inline, eval, specific domains), and outputs a copy-paste-ready Content-Security-Policy header.

How to use the Content Security Policy (CSP) Builder

Use a preset for a quick start, then tweak. Each directive has a source list; common values are buttons (self, unsafe-inline, data:, https:), and you can add custom domains.

Building a Content-Security-Policy header

A Content-Security-Policy is one of the most effective defences against cross-site scripting, but also one of the easiest headers to get wrong: too strict and you block your own scripts, styles, and fonts; too loose and it offers little protection. The syntax is a list of per-resource directives, each with its own source list, and a single mistake can silently break a page or quietly defeat the policy.

This builds the header directive by directive — script-src, style-src, img-src, and the rest — with source toggles for self, inline, eval, data:, and custom domains, plus presets for common setups like AdSense and analytics. It produces the header value; add it through your server config (the .htaccess generator for Apache or the nginx config generator for nginx), and once it is live, paste your response headers into the HTTP headers explainer to confirm the policy and spot anything still missing.

Common use cases

• XSS hardening — restrict where scripts and styles are allowed to load from.
• Third-party scripts — allow exactly the analytics or ad domains you use, nothing more.
• Migrating to CSP — start from a preset and tighten it without breaking the page.
• Report-only testing — trial a policy in report mode before enforcing it.
• Audit fixes — supply the CSP header an audit said was missing.