Content-Security-Policy

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

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

Heroicons are the easy case for CSP, which is nice for once. If you use Heroicons the normal way — React components, Vue components, Blade components, or copied inline SVG markup — Heroicons do not require their own domain in your Content Security Policy. There’s no Heroicons CDN you need to allow. No remote script. No remote font. Usually no remote image either. That means your CSP for Heroicons is mostly about how you render the SVGs. ...

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

C3.js is handy because it gets you from raw data to charts fast. It’s also one of those libraries that tends to expose every weak spot in a sloppy Content Security Policy. I’ve seen teams lock down CSP, deploy C3.js, and then spend an afternoon wondering why the chart container stays blank while the console screams about blocked scripts or styles. Usually the breakage isn’t C3 itself. It’s the mix of D3, inline config, CDN habits, and CSS assumptions. ...