Security-Headers

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

Content Security Policy failures are easy to create and annoying to debug. They get even worse in production, where the browser console you rely on locally is now replaced by partial reports, CDN layers, injected third-party scripts, and users who only say “the page is broken.” I’ve dealt with this enough times to have a strong opinion: debugging CSP in production is less about one perfect tool and more about choosing the right signal. Browser errors, violation reports, header inspection, and controlled rollout all give you different slices of the truth. ...

AWS Cognito Hosted UI is convenient right up until you want a serious Content Security Policy. Then you hit the wall: you don’t control the response headers for the managed login pages the way you would on your own app. That changes how you think about CSP completely. This guide is the practical version: what you can and can’t do, where CSP actually applies, and copy-paste examples for the setups I see most often. ...

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

I’ve seen a lot of Rails apps with one of two CSP setups: no policy at all a policy that exists mostly to silence browser errors Neither gives you much protection. Rails actually makes CSP pretty workable, especially once you stop treating it like a static header and start treating it like application code. Here’s a real-world style case study based on the kind of policy you’ll see on production marketing and SaaS sites, including analytics, consent tooling, WebSockets, and a few legacy frontend habits that make CSP harder than it should be. ...