Headers

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

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

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

Evergreen by Segment is one of those tools that quietly expands your CSP over time if you’re not paying attention. You start with a neat script-src, then analytics, edge APIs, previews, and embedded UI bits show up and your policy turns into a junk drawer. This guide is the version I wish I had when wiring CSP around Evergreen on a production site. I’m assuming you want copy-paste examples first, with enough explanation to avoid breaking your app. ...

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

Clarity gives you a solid design system. CSP gives you a solid boundary. The annoying part is getting both to cooperate without punching holes in your policy. If you’re using VMware Clarity and trying to keep a sane Content Security Policy, the trade-offs are pretty familiar: developer ergonomics vs actual security, static hosting vs runtime nonces, and “just make it work” vs “I’d like to block XSS this year.” This guide compares the main ways teams approach CSP with Clarity-heavy apps, where the pain usually shows up, and what I’d recommend in practice. ...

Bunny Fonts is one of the easier font providers to support in Content Security Policy, mostly because the setup is simple and the domains are predictable. If you just want the working policy, here it is: Content-Security-Policy: default-src 'self'; style-src 'self' https://fonts.bunny.net; font-src 'self' https://fonts.bunny.net; img-src 'self' data:; script-src 'self'; connect-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'; That covers the common case where your page loads CSS from Bunny Fonts and then loads font files from the same host. ...