React

Fluent UI is great until you turn on a real Content Security Policy and your app suddenly looks half-broken. I’ve hit this a few times with React apps using Fluent UI. Buttons still render, but spacing is off, icons disappear, focus styles get weird, and the console starts yelling about blocked styles. The root cause is usually the same: Fluent UI has historically relied on runtime style injection, and strict CSP setups don’t like that unless you wire things correctly. ...

Visx is one of those rare charting libraries I actually like using. It gives you low-level control, stays close to SVG, and doesn’t drag in a giant black-box runtime. From a CSP perspective, that’s good news. The short version: Visx itself is usually CSP-friendly. It renders React components into SVG and doesn’t need eval, inline scripts, or weird dynamic code loading. Most CSP breakage around Visx comes from the app around it: tooltips, inline styles, custom HTML labels, analytics, and dev tooling. ...

CSS-in-JS is great right up until you try to lock down style-src. That’s where the friction starts. Many CSS-in-JS libraries inject <style> tags at runtime, and CSP treats those as inline styles. If your policy is strict, those styles get blocked unless you loosen style-src or add a nonce. I’ve seen teams spend weeks tightening script-src only to quietly leave style-src 'unsafe-inline' in place because Emotion, styled-components, JSS, or a legacy UI kit needed it. That usually happens because CSS-in-JS was adopted for developer experience, while CSP got added later under security pressure. ...

Theme UI is great until you turn on a real Content Security Policy and half your styling disappears. I’ve hit this a few times with React apps that looked perfectly fine in development, then blew up the moment a stricter CSP landed in production. Theme UI makes styling ergonomic, but it also leans on runtime style injection. That’s exactly where people get tripped up. If you’re locking down a Theme UI app, the biggest mistakes usually come from treating CSP like a static checklist instead of something that has to match how your app actually renders styles and scripts. ...

Ariakit is a headless UI toolkit, which is good news for CSP. It doesn’t force a CSS-in-JS runtime, it doesn’t need eval, and it generally stays out of your way. That means you can run a pretty strict Content Security Policy without fighting your component library. The tricky part usually isn’t Ariakit itself. It’s your app shell, analytics, consent tools, inline bootstrapping scripts, and whatever your framework injects during hydration. ...

I hit this problem on a React app using Grommet and grommet-icons: the app looked fine locally, then icons mysteriously disappeared once I tightened the Content Security Policy. No console errors about JavaScript failures. No broken imports. Just empty spaces where icons should be. That kind of bug is annoying because it looks like a UI issue, but the root cause is security policy. Here’s the real-world version of what happened, what broke, and the CSP changes that fixed it without throwing the policy in the trash. ...

Carbon gives teams a solid design system, but it does not magically solve CSP. I’ve seen plenty of Carbon-based apps ship with a polished UI and a deeply unserious security header: default-src *, script-src 'unsafe-inline', or no CSP at all because “the charts broke.” That tradeoff usually happens when a team mixes Carbon with analytics, consent tooling, a React build pipeline, and a few “temporary” inline scripts that somehow survive for two years. ...

kepler.gl is one of those libraries that looks simple from the outside and then quietly pulls in a lot of browser features once you ship it: Web Workers, WebGL, map tiles, fonts, API calls, and often third-party basemaps. That makes Content Security Policy trickier than a plain React app. If you lock CSP down too early, kepler.gl usually breaks in non-obvious ways: blank map canvas workers failing to start tiles not loading icons or fonts disappearing map style JSON fetching but not rendering This guide is the practical version: what to allow, what usually breaks, and copy-paste CSP examples you can start from. ...

shadcn/ui gives you a weird CSP problem compared to most component libraries: it is not really a library in the classic sense. You copy components into your app, own the code, and then your CSP story becomes your problem. That is good for flexibility, but it also means there is no single “shadcn/ui CSP policy.” The right policy depends on how you render styles, whether you use theme scripts, whether you pull in analytics, and whether your app is static, SSR, or edge-rendered. ...

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