CSP Generator

Your Best Defense Against XSS

In 2023, cross-site scripting was still in OWASP’s Top 10. An attacker injects a malicious <script> tag into your page — through a comment field, a URL parameter, a stored payload in your database — and suddenly they’re stealing session cookies, redirecting users, or mining crypto in your visitors’ browsers.

Content Security Policy stops that. A CSP header tells the browser exactly which domains can serve scripts, styles, images, fonts, and frames. Anything not on the whitelist gets blocked. Even if an attacker manages to inject <script>alert('xss')</script> into your HTML, the browser refuses to execute it because inline scripts aren’t allowed.

The problem? CSP headers are a nightmare to write by hand. One missing directive and your Google Analytics breaks. One typo and your CDN-hosted fonts disappear. This tool lets you configure each directive visually and spits out the correct header string.

The Directives That Matter Most

default-src 'self' is your baseline. It restricts every resource type to your own domain unless you override it with a more specific directive.

script-src controls where JavaScript can load from. This is the big one for XSS prevention. Set it to 'self' plus any CDN domains you trust. Avoid 'unsafe-inline' like the plague — it lets any inline <script> tag run, which defeats the entire purpose. If you absolutely need inline scripts (some frameworks demand it), use nonces ('nonce-randomValue') or hashes ('sha256-...') to permit specific scripts only.

object-src 'none' blocks Flash and other plugin content. There’s basically no legitimate reason to allow this in 2026.

frame-ancestors 'none' prevents your page from being embedded in iframes, which stops clickjacking attacks.

style-src is where things get messy. Many CSS-in-JS libraries inject styles dynamically, which requires 'unsafe-inline'. It’s less dangerous than allowing inline scripts, but still weakens your policy.

Building Your Policy Step by Step

Hit “Apply Strict Defaults” to start with a locked-down baseline. Then open up specific directives for what your site actually needs:

• Using Google Fonts? Add fonts.googleapis.com to style-src and fonts.gstatic.com to font-src.
• Running Google Analytics? Add www.googletagmanager.com and www.google-analytics.com to script-src.
• Embedding YouTube videos? Add www.youtube.com to frame-src.

The header string updates in real time as you make changes. Copy it as an HTTP header value for Nginx/Apache/Express, or grab the HTML meta tag version.

Roll It Out Without Breaking Production

Don’t deploy a CSP in enforcement mode on day one. You’ll block legitimate resources and get a flood of support tickets.

Instead, start with Content-Security-Policy-Report-Only. This logs violations to the browser console (and optionally to a reporting endpoint) without actually blocking anything. Browse your site, check the console, and add missing sources to your policy. Once the violations dry up, switch to the enforcing header.

PCI DSS and SOC 2 auditors increasingly look for CSP headers. Having one — and being able to explain your directives — goes a long way during compliance reviews.

CSP vs. Meta Tag

You can deliver CSP as an HTTP header (set by your web server) or as a <meta> tag in your HTML. The header is better. It applies before the browser starts parsing the page, and it supports directives like frame-ancestors and report-uri that the meta tag can’t handle.

Use the meta tag as a fallback if you don’t have control over your server headers — like when you’re hosting on a static platform that doesn’t let you configure response headers.

The CORS Generator on Toolsvu handles cross-origin resource sharing headers through a similar visual builder.