Frontend

When people talk about Content Security Policy, they usually picture a single app with a single header set by a single server. That’s not how most production systems look anymore. A real microservices setup is messy. You have an edge proxy, maybe an API gateway, a frontend service doing SSR, a couple of backend APIs, static assets on a CDN, analytics scripts that marketing swears are non-negotiable, and at least one service that still injects inline JavaScript because “that’s how the template engine works.” ...

A/B testing tools and strict CSP have a messy relationship. VWO is a good example. Marketing wants fast experiments. Security wants a locked-down policy. Engineering gets stuck in the middle, usually after someone ships unsafe-inline and calls it “temporary.” I’ve had to clean this up more than once. If you’re running VWO on a site with a real Content Security Policy, you need to make a choice: loosen CSP enough for VWO to work easily, or keep a stricter policy and accept extra setup, testing, and occasional friction. ...

JSFiddle embeds look harmless until your CSP blocks them and your page turns into an empty rectangle. I’ve seen this happen a lot: someone adds a fiddle iframe to docs, tutorials, or a demo page, then ships a tight CSP and suddenly the embed refuses to load. The browser console says something vague about frame-src, maybe script-src, and now everyone is guessing. JSFiddle embeds are a good example of how CSP failures usually come from one or two small misunderstandings, not from some giant policy disaster. Here are the mistakes I see most often, and the fixes that actually work. ...

Feature flags sound harmless until they turn into “run arbitrary code from a remote dashboard.” I’ve seen teams build a custom flag system, then quietly smuggle in dynamic script loading, inline config blobs, third-party SDKs, and admin-controlled HTML. That’s exactly where Content Security Policy starts pulling its weight. If you’re building a custom flag system, CSP won’t design it for you. What it does is force you to be honest about how the system actually works. Are flags just booleans? Are they JSON payloads? Do they decide which already-shipped component renders? Or are they effectively a remote code execution mechanism with nicer branding? ...

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. ...