Csp

Web fonts are one of those things teams barely think about until the site starts flashing invisible text, Lighthouse complains, or CSP suddenly blocks production traffic. I’ve seen this happen a lot: someone tightens Content Security Policy, feels good about shipping a safer header, and then fonts start failing in subtle ways. Not always completely broken. Sometimes they just get slower. And slow fonts are nasty because they hurt rendering, CLS, and perceived quality without looking like an obvious outage. ...

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

Teams love dropping Loom videos into internal portals, onboarding hubs, help centers, and customer dashboards. Security teams usually hate how fast those embeds spread. I’ve seen this pattern a lot: a portal starts with one harmless embedded video, then picks up analytics, a consent banner, a chat widget, and a couple of “temporary” inline scripts that never go away. The CSP ends up either too loose to matter or so strict that Loom breaks in production. ...

Nivo is usually a pretty easy fit for a strict Content Security Policy. That’s the good news. The catch is that teams often blame the charting library when the real CSP breakage comes from everything around it: analytics, consent banners, custom fonts, exported images, server-side rendering, or a dev setup that quietly relies on unsafe-eval. If you’re adding Nivo charts to a production app and want a sane CSP, here’s how I’d approach it. ...

Teams usually treat icons as harmless. They are tiny, static, and easy to ignore in a CSP rollout. Then the first production deploy lands and half the UI loses its glyphs, the marketing tag manager still works, and somebody “fixes” it by adding img-src * data:. I’ve seen this happen more than once. This case study is about a site I’ll call Bytesize Icons: a developer-facing site with a searchable icon catalog, docs pages, a React app shell, analytics, and consent tooling. The goal was simple: lock down CSP without breaking icon rendering. ...

If you want to embed Eraser in a site with a sane Content Security Policy, you have a few choices. None of them are perfect. The right one depends on whether you care more about tight isolation, easy maintenance, or preserving a very strict policy posture. I’ve had to make this tradeoff on production apps, and the pattern is always the same: the embed itself is easy, the CSP around it is where the mess starts. ...

UnoCSS is great until you turn on a strict Content Security Policy and your styling quietly falls apart. That’s the tradeoff with on-demand atomic CSS. UnoCSS can inject styles at runtime, and CSP tends to hate runtime injection unless you explicitly allow it. If you’ve ever tightened style-src and then watched your app render as unstyled HTML, you’ve already met the problem. The short version: if UnoCSS is generating or injecting <style> tags in the browser, you need to account for that in CSP. If you can shift style generation to build time or server render time, life gets much easier. ...

Adobe Fonts is one of those integrations that looks trivial until your CSP starts blocking it in production. You add the embed code, ship a strict policy, and suddenly your typography falls back to system fonts. Or worse, you loosen style-src too much just to get it working and quietly undo a big chunk of your CSP hardening. I’ve had to clean this up more than once. The good news: Adobe Fonts usually needs only a small set of allowances. The bad news: a lot of examples online are either too broad or copy-pasted from unrelated setups. ...

Vanilla Extract is one of the easier styling tools to live with under a strict Content Security Policy. That’s the good news. The reason is simple: Vanilla Extract compiles styles to real CSS files at build time. No runtime style injection, no CSS-in-JS engine pushing <style> tags into the DOM on page load, no constant fight with style-src nonces. If you care about CSP, that’s already a huge win. Still, “works better with CSP” is not the same thing as “done.” Teams often ship a decent script-src and then quietly leave style-src 'unsafe-inline' hanging around forever because some analytics tool, consent manager, or framework edge case made it convenient. ...

SoundCloud embeds look simple: paste an <iframe>, ship it, done. Then CSP gets involved and the player disappears, the console fills with violations, and somebody “fixes” it by slapping https: into half the policy. That’s the usual failure mode. If you’re embedding SoundCloud on a site with a real Content Security Policy, the trick is to allow exactly what the embed needs and nothing else. Most breakages come from guessing the wrong directive, overusing default-src, or trying to force a third-party widget into a policy designed only for first-party code. ...