Web & Hosting

CSP Builder

Build a Content-Security-Policy from plain choices — which script and style sources to trust, whether to allow inline code, how to handle images and whether other sites may embed you. A good CSP is the single biggest defense against cross-site scripting and clickjacking.

Try it now

💡 Good to know: A solid Content-Security-Policy is the single most effective defense against cross-site scripting (XSS).

Worked example

# Content-Security-Policy — pick ONE delivery method. ## As an HTTP header (best — add to your _headers file): Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; font-src 'self'; connect-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'; form-action 'self' ## As a <meta> tag (fallback when you can't set headers): <meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; font-src 'self'; connect-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'; form-action 'self'"> # Test it: open the browser console — any violation logs the exact directive to fix.

Learn the method

Inputs

Extra script origins (space-sep)
Extra style origins (space-sep)
Allow inline scripts
No / Yes
Allow inline styles
Yes / No
Images
self + data: / self only / any https
Can other sites embed you?
Block (frame-ancestors none) / Allow same-origin

Frequently asked

Header or meta tag?

Prefer the HTTP header (put it in your _headers file) — it's stronger and covers more directives. The <meta> version is a fallback when you can't set headers.

Why avoid 'unsafe-inline'?

It lets any inline <script> run, which defeats much of the point of a CSP. Move scripts to files and keep it off if you can.