Headers

I’ve seen a bunch of teams do the same thing with Content Security Policy on Nginx: they add one header at the reverse proxy, ship it, and assume the app is now “protected.” Then analytics breaks, consent banners disappear, WebSocket calls fail, and somebody quietly removes the header on Friday evening. That usually happens because CSP at the reverse proxy layer is not just “set a header.” It’s policy design, inheritance, proxy behavior, and app rendering all tangled together. ...

If you’re choosing between CSP hashes and nonces, the short version is this: Use nonces when your page is rendered dynamically and you control the HTML response. Use hashes when the inline code is static and rarely changes. If you’re dealing with modern third-party loaders, nonce + strict-dynamic is usually the cleanest option. I’ve seen teams overcomplicate this. CSP gets much easier once you stop treating hashes and nonces as interchangeable. They solve similar problems, but they fit very different delivery models. ...

Content Security Policy on WooCommerce sites is where good intentions go to die. I’ve seen teams turn on a “strict” CSP, feel great for five minutes, then realize checkout is broken, Stripe fields don’t load, product images disappear from the CDN, and marketing starts yelling because GA4 went dark. E-commerce is one of the hardest places to deploy CSP well because a store is never just your code. It’s your theme, plugins, payment providers, tag managers, fraud tools, cookie banners, live chat, analytics, A/B testing, and whatever one-off script someone added during Black Friday. ...

Educational platforms are a CSP minefield. A normal marketing site might load a few scripts, an analytics tag, and maybe a video embed. An LMS loads SSO flows, SCORM packages, grading tools, PDFs, discussion widgets, proctoring apps, webinar platforms, analytics, and random third-party course content written by people who have never heard of CSP. So the trick is not “make CSP strict at all costs.” The trick is building a policy that blocks obvious abuse without breaking the actual learning experience. ...

Content Security Policy and Subresource Integrity solve different problems, and they work best when you treat them as a pair. CSP answers: what sources am I willing to trust? SRI answers: is this exact file the one I meant to load? That distinction matters. I still see teams deploy one and assume they’re covered. They’re not. If you load a third-party script from an allowed domain in CSP, CSP is happy. But if that third-party file changes unexpectedly, CSP won’t help. SRI will. ...

Content Security Policy has a reputation problem. A lot of teams either treat CSP like a magic anti-XSS shield, or they avoid it because they assume it will break everything. Both takes are wrong. CSP is powerful, but it’s also easy to misuse in ways that give you a nice-looking header and very little real protection. I’ve seen plenty of production policies that look serious because they’re long, but collapse the moment an inline script sneaks in or a third-party script gets too much trust. ...

Next.js developers usually think about CSP at the page level: block inline scripts, add nonces, lock down third-party tags. That’s the right instinct, but API routes deserve attention too. Strictly speaking, CSP is mostly a browser-enforced policy for documents and some subresources. Your JSON API endpoint isn’t executing scripts in the browser, so a Content-Security-Policy header on /api/users won’t do much for a normal application/json response. That’s the part people skip. ...

Government websites have a rough CSP problem. I’ve seen the same pattern over and over: a site adds a Content Security Policy because a scanner demanded it, ships a giant allowlist, sprinkles in 'unsafe-inline', and calls it done. The header exists, the compliance box gets checked, and the actual XSS risk barely moves. That’s not a government-specific technical limitation. It’s mostly a procurement, legacy platform, and “don’t break the citizen-facing form” problem. ...

Let me be blunt: if you’re not running Content Security Policy on your website, you’re leaving the front door wide open for Cross-Site Scripting (XSS) attacks. And no, input sanitization isn’t enough. It never has been. I’ve seen countless security audit reports where everything looks great on paper — input validation, output encoding, WAF rules — but one missing CSP header turns all of that into a suggestion rather than a guarantee. ...

I’ve seen too many CSP implementation guides that show you a perfect policy for a perfect application and pretend everything will just work. In the real world, implementing CSP is messy. You’ll hit issues you didn’t expect. Your CMS will inject inline scripts you forgot about. That analytics tool your marketing team added last quarter? It breaks everything. This guide is for people implementing CSP on real applications. Not demos. Not fresh create-react-app projects. The kind of application that has accumulated technical debt, third-party scripts, and “temporary” hacks that have been there for three years. ...