React

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

If you use Stitches, CSP gets awkward fast. The problem is simple: Stitches is a CSS-in-JS library, and CSP is usually hostile to anything that injects styles at runtime. That does not mean they cannot work together. It means you need to be deliberate about how styles are rendered, when they are injected, and which CSP directives you allow. I’ve seen teams ship a pretty solid script-src policy, then quietly leave style-src 'unsafe-inline' forever because CSS-in-JS made cleanup feel painful. That is usually where the security story falls apart. ...

Ant Design is one of those UI libraries that looks harmless from a CSP perspective until you actually turn on a strict policy. Then things get weird fast: styles stop rendering, wave effects break, overlays look unstyled, and your console fills with CSP violations. I’ve hit this enough times that I treat Ant Design as a “plan CSP early” dependency, not a “bolt it on later” one. The main issue is styling. Depending on your Ant Design version and setup, the library may inject styles dynamically. A strict style-src can block that unless you configure nonces properly. If you’re also using server-side rendering, React hydration, analytics, and a consent manager, the policy gets more realistic than a toy default-src 'self'. ...

Material UI is one of those libraries that makes frontend teams fast and security teams nervous. The problem is simple: MUI relies on runtime-generated CSS. CSP, if you configure it properly, is hostile to runtime-generated inline styles unless you make an exception. That tension forces a choice: loosen your policy, wire up nonces correctly, or rethink how styles are injected. If you’re building with MUI, the right CSP setup depends on which styling path you’re using: ...

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