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. ...
goober is tiny, fast, and refreshingly unpretentious. That’s exactly why people like it. But the moment you try to lock down a real app with Content Security Policy, CSS-in-JS stops being a styling choice and starts becoming a security deployment problem. The short version: goober usually injects styles into <style> tags at runtime. CSP cares a lot about that. If your policy is strict, those injected styles can get blocked unless you deliberately allow them. ...
Chart.js v4 is one of the easier charting libraries to run under a strict Content Security Policy. That’s the good news. The less fun part: “easier” does not mean “automatic.” The moment you mix Chart.js with inline bootstrapping code, third-party plugins, CDN delivery, tag managers, or framework hydration tricks, your policy gets messy fast. I’ve had to clean this up more than once, and the pattern is always the same: the chart library itself is usually fine, but the surrounding app code quietly punches holes in CSP. ...
Sass + CSS Modules usually feels boring in the best possible way. You write .module.scss, import it into a component, get locally scoped class names, and move on with your life. Then CSP shows up and breaks your build in ways that are annoyingly indirect. The tricky part is that Sass CSS Modules themselves are not the problem. The problem is how your toolchain delivers the compiled CSS to the browser. Some setups emit static .css files. Others inject <style> tags at runtime. CSP treats those very differently. ...