Css-in-Js

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