Content Security Policy builder, importer, risk checker and server snippet generator
A CSP I hand-wrote once took a site down for twenty minutes. I’d forgotten the analytics host. So I built this to stop repeating that exact mistake. Pick a preset (WordPress, a static site, a dashboard, an API) or paste a header you already run and let it untangle the thing. It flags what’s risky. It writes you a report-only or enforcing header. Then it hands over snippets you can paste straight into Apache or Nginx or Netlify or Vercel. And honestly it nags you to test first, because I learned that bit with a live site and a sinking feeling.
Ship report-only first. Trust me on this one. A CSP earns its keep. But enforce it with one host missing and your ads go dark, your analytics stops reporting, embeds and forms quietly die, and half your plugins start throwing a fit.
A CSP should be rolled out carefully, not copied blindly
So here’s the deal with a CSP. Good day, it blunts cross-site scripting and slams the door on mixed content plus whatever random third-party junk you never asked for. Bad day, one missing source and it nukes a script, a stylesheet, a font, an image, an embed, a form or your analytics, and the page just breaks. That whole tension is why I wanted a builder that puts the real header in front of me, tells me what I’m trading away, flags the hardening I always forget, then spits out the snippets so I can test before any of it goes live.
That’s what this does. Built for shipping, not for looking clever. There are profiles for WordPress, static sites, SaaS, and a strict starter you can grow into. It swallows a header you paste, quietly fixes the curly quotes WordPress loves to mangle, and yells the moment it spots unsafe-inline, unsafe-eval, a wildcard, or a plain http source. Report-only or enforcing, your call. Snippets for Apache, Nginx, Netlify, Vercel, plus a meta-tag fallback for when you’re stuck. I’m not promising a flawless policy in one click. Nobody can. I just want you shipping a better one without taking production down with it.
How to test a Content Security Policy
Flip it to report-only. Then actually click around the pages that earn money or do real work: the homepage, an article, the login, anything with a form or a checkout, a YouTube embed, an ad slot, your analytics, the comments, the admin screens. Open the console. Read what it complains about, and add back only the hosts you genuinely use. Don’t get lazy and paste a wildcard. Once the reports stop screaming you can switch to enforce, and keep half an eye on it whenever you touch a plugin or a theme or anything inside tag manager, because that’s usually what breaks it next.
- default-src is your safety net. It’s the fallback when nothing more specific matches.
- script-src is the one I lose sleep over, because scripts are where XSS actually gets you.
- object-src ‘none’ kills off ancient Flash-era plugin junk you’ll never want back.
- base-uri ‘self’ stops an injected base tag from quietly rewriting where your URLs point.
- frame-ancestors decides who’s allowed to drop your page in an iframe. Clickjackers, not so much.
Common CSP debugging examples
Script getting blocked? Add the one exact host it’s whining about, not a wildcard you’ll regret by Friday. Stuck with inline scripts because WordPress or tag manager won’t let go of them? Stay in report-only and pencil in a nonce, or a refactor, for later. Just don’t paper over it. Fonts not loading is the classic gotcha, because two directives are in play at once: style-src for the stylesheet from the CSS provider, and font-src for the actual font files. People forget that second one every single time. YouTube embed vanished? Nearly always frame-src missing the YouTube host. And when a form silently stops submitting and you’ve genuinely no idea why, go stare at form-action first.
Common questions
Should I use report-only first?
Always. On a live site I won’t even entertain another way of doing it. Report-only dumps every violation into the console while breaking nothing at all for your visitors, so you see the whole picture before a single user notices anything is off.
Is unsafe-inline always bad?
It pokes a hole in the exact protection you’re standing up. So yeah, not great. I might be wrong here, but I treat it as tolerable for a stretch on a gnarly WordPress site that won’t behave, filed under debt I owe and mean to pay down. Never a setting I’m content to leave forever.
Can I put CSP in a meta tag?
You can. Once in a blue moon you have to. But a real HTTP header wins every time, because it’s more reliable and it carries directives a meta tag simply can’t express. I only drop to the meta tag when setting headers is genuinely off the table, like on some locked-down shared host.
What does a Content Security Policy protect against?
Mostly cross-site scripting and injected content. You hand it a list of the hosts your scripts and styles and everything else are allowed to load from. Anything off that list, including code an attacker smuggles in, just never gets to run.
Why should I avoid unsafe-inline and unsafe-eval?
They hand back the very key CSP was built to take away. unsafe-inline lets injected inline scripts run. unsafe-eval lets strings turn into live code, which is exactly the thing you’re trying to stop. For the inline bits you truly can’t dodge, reach for a nonce or a hash instead.
How do I roll out a CSP without breaking the site?
Lead with Content-Security-Policy-Report-Only so violations pile up in your reports while nothing actually gets blocked. Work down the list and allow the sources that are legit. Only once the reports go quiet do you swap in the enforcing header. Slow and a bit boring is the move.
