Split.io is easy to miss in a CSP until your flags stop loading and your app quietly falls back to defaults. I’ve seen this happen a lot: the SDK loads fine from your own bundle, but CSP blocks the network calls Split needs for streaming, polling, or event tracking. The result is subtle. No obvious crash, just “why are all my feature flags off in production?” This guide is the copy-paste version for getting Split.io working with Content Security Policy. ...
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. ...
Adyen is one of those integrations where CSP gets real fast. A normal marketing site can get away with a basic policy and a couple of allowlists. Payments are different. You’re loading third-party scripts, embedding frames, sending XHR requests to payment endpoints, and sometimes dealing with redirects or 3D Secure flows. If your CSP is too strict, checkout breaks. Too loose, and you’ve basically given up the point of having CSP. ...
HubSpot chat is one of those integrations that looks trivial right up until CSP starts blocking half of it. I’ve seen this pattern a lot: the base site already has a decent policy, someone drops in the HubSpot tracking/chat script, the widget silently fails, and the first reaction is to throw 'unsafe-inline' or https: into the policy until the errors go away. That works, but it also wrecks the whole point of having CSP. ...
FullStory is one of those tools that security teams side-eye and product teams love. Session replay, event capture, rage clicks, funnels — great for debugging real user behavior, but it also means you’re injecting a third-party script that phones home constantly. That makes Content Security Policy a real concern, not a checkbox. If you add FullStory without thinking through CSP, you usually get one of two outcomes: FullStory silently breaks and nobody notices until analytics goes dark. Someone opens the policy way too far with https: and 'unsafe-inline', and now your CSP is mostly decorative. I’d rather avoid both. ...
If you build web apps, CSP is one of those controls that feels clean and satisfying. You define what the browser may load, block everything else, and sleep a little better. Then email shows up and ruins the neat mental model. CSP for email templates and HTML emails sounds like a natural extension of web security. Same HTML, same browser engine somewhere in the stack, same risks from injected content. But email clients are a different universe. Some strip tags. Some rewrite links. Some proxy images. Some ignore modern security controls entirely. And many of them treat your carefully crafted HTML like a suspicious package. ...
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. ...
Browser extensions make CSP debugging weird. You lock down script-src, remove inline code, add nonces, maybe even deploy strict-dynamic, and then someone on the team says: “Why is this extension still injecting stuff into our page?” Or worse: “Why is our app breaking only for users with ad blockers?” That confusion usually comes from one bad assumption: people expect a site’s CSP to control browser extensions the same way it controls page code. It doesn’t. ...