Css-in-Js

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

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

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

Teams usually discover CSP problems with Linaria the annoying way: everything works in development, then production gets a stricter policy and styles start disappearing. I’ve seen this happen when a team moves from a relaxed policy to something closer to a real production header, like the one headertest.com sends: content-security-policy: default-src 'self' https://www.googletagmanager.com https://*.cookiebot.com https://*.google-analytics.com; script-src 'self' 'nonce-MjgzMGM0NjctNzg4MS00NTNiLThkN2UtNjY3N2VmMTRlOGUy' 'strict-dynamic' https://www.googletagmanager.com https://*.cookiebot.com https://*.google-analytics.com; style-src 'self' 'unsafe-inline' https://www.googletagmanager.com https://*.cookiebot.com https://consent.cookiebot.com; img-src 'self' data: https:; font-src 'self'; connect-src 'self' https://api.headertest.com https://tallycdn.com https://or.headertest.com wss://or.headertest.com https://*.google-analytics.com https://*.googletagmanager.com https://*.cookiebot.com; frame-src 'self' https://consentcdn.cookiebot.com; frame-ancestors 'none'; base-uri 'self'; form-action 'self'; object-src 'none' That header is realistic because it shows the usual compromise: strong script controls, but style-src 'unsafe-inline' left behind because CSS tooling got messy. ...