Posts

I’ve seen this exact problem a bunch of times: a team has a pretty decent Content Security Policy, marketing wants Intercom, someone pastes the vendor snippet into the site, and suddenly the browser console looks like a crime scene. The hard part isn’t getting Intercom to load. The hard part is getting it to load without wrecking a policy that was actually doing useful work. Here’s a realistic case study using a real baseline CSP from headertest.com, then tightening it up for Intercom live chat with minimal blast radius. ...

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

A/B testing sounds harmless until it collides with a strict Content Security Policy. That’s where teams usually get stuck with PostHog experiments. Product wants fast iteration. Security wants a locked-down CSP. Engineering gets to mediate the fight. I’ve dealt with this a few times, and the bad news is there’s no magic CSP switch for “safe experimentation.” The good news is you do have a few workable patterns, and each one has pretty clear tradeoffs. ...

tRPC feels deceptively simple from a CSP perspective. There’s no <script> injection problem in the RPC layer itself, so people assume CSP barely matters. Then production hits. Queries fail only in the browser. Subscriptions work locally but die behind a proxy. SSR is fine, client-side navigation breaks. Someone tightens default-src and suddenly your API calls start throwing opaque network errors. I’ve seen this more than once: the app is “secure” on paper, but the CSP doesn’t actually match how tRPC talks over HTTP and WebSockets. ...

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

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

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