Posts

CSP Examples Cookbook: Copy-Paste Security Headers Content Security Policy (CSP) is still one of the highest-impact browser defenses you can deploy in 2026. A good CSP reduces XSS risk, limits third-party script abuse, narrows data exfiltration paths, and makes supply-chain mistakes less catastrophic. The hard part is not the syntax. The hard part is shipping a policy that matches your stack. This cookbook gives you complete, copy-paste-ready CSP examples for common servers, frameworks, hosting platforms, and integrations. Each example is short, practical, and designed to be adapted with minimal changes. ...

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

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