Frontend

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

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

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

I’ve seen this exact failure pattern a few times: a team adds Mermaid to docs or an internal dashboard, the diagrams look great locally, then production CSP quietly wrecks everything. The symptoms are boring but expensive: diagrams don’t render initialization throws console errors someone “fixes” it by adding 'unsafe-inline' or weakening script-src now the page works, but the policy got worse Mermaid is a perfect example of where frontend convenience collides with a real CSP. If you run a site with a strict policy, you can’t just paste the snippet from a README and hope for the best. ...

CSS got weird again, in a good way. Between @layer, design tokens, component libraries, runtime theming, and CSS-in-JS leftovers, a lot of teams now have what I’d call an LSD setup: a Layer System for CSS. You split styles into predictable layers like reset, tokens, base, components, utilities, and overrides. That’s cleaner than the old cascade knife fight. But CSP can get awkward fast, especially when your CSS pipeline injects styles, swaps themes at runtime, or leans on inline <style> blocks. ...

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

Bandcamp embeds look simple right up until your CSP starts blocking them. You paste the iframe, refresh, and get a blank box or a console full of violations. I’ve seen this pattern a lot: teams lock down CSP correctly, then third-party embeds get boladted on later and nobody updates the policy with any care. The result is usually one of two bad outcomes: the embed breaks, or somebody “fixes” it by allowing way too much. Bandcamp is pretty tame compared to ad tech or social widgets, but there are still a few easy mistakes that keep showing up. Here’s what tends to go wrong, and how I’d fix it without turning your CSP into allow basically everything. ...

I’ve run into this exact problem a few times: a team tightens Content Security Policy, ships it to production, and suddenly half the icons vanish. Not SVG logos. Not a giant component library. Tiny CSS.gg icons. They look harmless because CSS.gg is “just CSS”. That’s exactly why they get people into trouble. CSS-based icon sets often depend on inline styles, pseudo-elements, CSS variables, or external stylesheets loaded from a CDN. All of those can collide with a strict style-src. ...

If you’re building a Foundation site, CSP usually gets messy in two places fast: JavaScript plugins and inline styles. Foundation itself isn’t uniquely hard to secure, but the usual stack around it—jQuery, what-input, CDN assets, analytics, consent banners—turns a clean policy into a pile of exceptions if you’re not careful. This guide is the version I wish I had when tightening CSP on a real Foundation app: minimal theory, lots of working policies. ...

Highcharts is one of those libraries that usually works fine until you turn on a real Content Security Policy. Then the fun starts: tooltips stop rendering, exports break, inline styles get blocked, and you end up staring at DevTools wondering which directive is yelling at you this time. I’ve had better results treating Highcharts like any other third-party JavaScript dependency: start with a strict CSP, load only what you need, and loosen the policy only when you can prove why. ...