Iframe

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

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

DartPad-style apps are a weird CSP target. You’re not just serving a normal frontend. You’ve got inline bootstrapping code, dynamic script loading, iframes, workers, API calls, maybe WebSockets, and often some analytics or consent tooling bolted on top. That combination is exactly where people give up and slap unsafe-inline and unsafe-eval into production. I’ve done that under deadline pressure. I’ve regretted it every time. If you’re building something like DartPad, the goal is to allow the platform features you actually need without turning CSP into decorative security theater. ...

If you embed Whimsical and your CSP is even slightly too strict, it will break in ways that are annoying to debug. Usually you get a blank iframe, a console error, and a vague sense that CSP is punishing you for trying to ship something useful. Here’s the good news: Whimsical embeds are usually straightforward because they’re iframe-based. That means you often only need to allow the Whimsical frame itself, instead of opening up script-src or connect-src all over your app. ...

Replit embeds are usually simple right up until CSP gets involved. You drop in an iframe, everything looks fine locally, then production blocks it with a vague browser error. Or worse, your CSP is broad enough that it works, but now you’ve punched a bigger hole in your policy than you meant to. This guide is the version I wish I had handy the last few times I dealt with third-party embeds. ...

If you embed tldraw in a page, your CSP usually breaks in one of three places: the iframe itself gets blocked tldraw can load, but its network calls fail collaborative features fail because WebSocket or worker policies are too tight This guide is the practical version: what to allow, what to avoid, and copy-paste policies you can start with. I’m assuming you already know basic CSP syntax. If you need a refresher on directives, https://csp-guide.com is a solid reference. ...

I’ve had to fix this exact problem more than once: design wants an InVision prototype embedded on a marketing page or internal docs site, everything works locally, then production CSP blocks it hard. The usual bad fix is “just allow everything from https: in frame-src and script-src.” That gets the demo unblocked and quietly wrecks the value of CSP. A better fix is boring and precise: figure out exactly what the embed needs, add the minimum policy changes, and verify you didn’t loosen unrelated directives. ...

If you’ve ever dropped a Mixcloud embed into a page and watched it fail under a strict Content Security Policy, you already know the pattern: the iframe looks harmless, but CSP doesn’t care about harmless. It cares about explicit allowlists. I’ve run into this a lot on sites that already have a decent CSP and then bolt on third-party media later. Everything is locked down, then one product request lands: “Can we embed this Mixcloud show by Friday?” ...

If you want to drop a Deezer player into a page without punching unnecessary holes in your Content Security Policy, you’ve got a couple of decent options and one bad habit to avoid. The bad habit is the usual one: something breaks, you sprinkle domains across default-src, maybe throw in https: for good measure, and call it done. That works right up until your CSP stops being a security control and becomes decorative wallpaper. ...

JSFiddle embeds look harmless until your CSP blocks them or, worse, you punch a giant hole in your policy just to make one iframe work. I’ve seen teams “fix” this by slapping frame-src * or default-src https: into production. That works, but it also guts the point of having CSP in the first place. If you only need to embed JSFiddle, you should allow exactly JSFiddle and nothing else. What a JSFiddle embed actually needs A typical JSFiddle embed is just an iframe: ...