Web-Security

If you embed Balsamiq mockups on a site with a real Content Security Policy, you hit the usual tradeoff fast: keep the policy tight, or make the embed work with the least drama. I’ve dealt with this enough times that I now split the problem into a few clear patterns. Balsamiq embeds are usually easiest when treated as a framed third-party app. The hard part is not Balsamiq itself. The hard part is everything around it: analytics, consent tools, inline styles, legacy scripts, and whatever your framework injects. ...

Variable fonts look simple from the design side: one font file, multiple weights, less asset sprawl. Then CSP gets involved and suddenly your typography falls back to Arial in production while everything worked fine locally. I’ve seen this happen a lot. Teams lock down script-src, spend hours on nonces, and then leave fonts as an afterthought. With variable fonts, that gets messy fast because the loading path usually crosses CSS, font files, CDNs, and sometimes inline styles from third-party tools. ...

Emotion is great until you turn on a real Content Security Policy and your app suddenly looks naked. That’s the usual collision: Emotion injects styles at runtime with <style> tags, while CSP blocks inline styles unless you explicitly allow them. A lot of teams “fix” that by adding 'unsafe-inline' to style-src, which defeats a big chunk of why you enabled CSP in the first place. If you’re using Emotion on a production app, the right fix is usually a nonce-based CSP and making sure Emotion attaches that nonce to every injected style tag. ...

Stripe Elements is one of those integrations that looks simple until CSP gets involved. The moment you lock down script-src, frame-src, and connect-src, your payment form can go from “works great” to “card field is blank and nobody knows why.” I’ve seen teams waste hours debugging this because Stripe is doing exactly what it should do: loading payment UI in isolated iframes, talking to Stripe APIs, and sometimes pulling in supporting assets from Stripe-controlled domains. CSP needs to allow that behavior without turning your policy into a giant wildcard mess. ...

If you’ve ever dropped a Miro embed into a page and thought “it’s just an iframe, this should be easy,” CSP will usually humble you pretty fast. Miro embeds are one of those cases where a policy that looks clean and locked down can still fail in annoying ways. The iframe might not render, the board shell loads but stays blank, assets get blocked, or collaboration features quietly break because a websocket or worker got denied. ...

If you embed Zeplin content and your CSP is even slightly too strict, the embed breaks in annoying ways: blank iframe, blocked scripts, missing fonts, or silent failures that only show up in DevTools. I’ve had to debug enough third-party embeds to know the pattern: start narrow, inspect what gets blocked, then add only what the embed actually needs. Don’t cargo-cult a giant allowlist. This guide is a practical reference for getting Zeplin embeds working with CSP, with copy-paste examples you can use as a starting point. ...

Embedding YouTube looks simple right up until CSP starts blocking half of it. You add an <iframe>, refresh the page, and suddenly the browser console is yelling about frame-src, img-src, or some random googlevideo.com request you didn’t explicitly ask for. That’s normal. YouTube embeds pull in more than just youtube.com, and playlists add a couple more moving parts. Here’s the practical reference I wish I had the first few times I locked this down. ...

GitHub buttons look harmless. They’re tiny. They show a star count. They make product people happy. They also pull in third-party resources, which means they touch your Content Security Policy. If your CSP is strict — and it should be — GitHub buttons are one of those “why is this blocked?” annoyances that show up late in a launch checklist. Here’s how I handle them without turning CSP into mush. ...

Running a TypeScript playground is where nice, clean CSP ideas go to get punched in the face. You want a browser app that accepts arbitrary code, transpiles it, maybe runs it in a preview, stores snippets, loads analytics, and still keeps a tight Content Security Policy. That combination gets messy fast. I’ve built this kind of thing before, and the first version usually cheats: unsafe-inline, unsafe-eval, and a quiet promise to “fix it later.” ...

If you use Stitches, CSP gets awkward fast. The problem is simple: Stitches is a CSS-in-JS library, and CSP is usually hostile to anything that injects styles at runtime. That does not mean they cannot work together. It means you need to be deliberate about how styles are rendered, when they are injected, and which CSP directives you allow. I’ve seen teams ship a pretty solid script-src policy, then quietly leave style-src 'unsafe-inline' forever because CSS-in-JS made cleanup feel painful. That is usually where the security story falls apart. ...