Css

CSS got weird again, in a good way. Between @layer, design tokens, component libraries, runtime theming, and CSS-in-JS leftovers, a lot of teams now have what I’d call an LSD setup: a Layer System for CSS. You split styles into predictable layers like reset, tokens, base, components, utilities, and overrides. That’s cleaner than the old cascade knife fight. But CSP can get awkward fast, especially when your CSS pipeline injects styles, swaps themes at runtime, or leans on inline <style> blocks. ...

Pico.css is refreshingly boring in the best way. Drop in one stylesheet, get decent defaults, move on with your life. That simplicity tricks people into thinking CSP will be simple too. Usually it is — until someone adds a CDN link, a theme switcher, a bit of inline CSS, or a framework that sneaks in runtime style injection. Then your “tiny CSS setup” turns into a pile of CSP violations. ...

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

Water.css is the kind of CSS framework I like for security work: tiny, boring, and mostly predictable. That matters for CSP because every extra build step, inline style hack, or third-party asset is another thing you need to allow. If you’re using Water.css, your CSP can usually stay tight. Most setups only need to allow your own origin for styles, or a single CDN if you’re loading it remotely. What Water.css changes in CSP Water.css is just a stylesheet. In the normal case, CSP impact is limited to: ...

NeoMagic.css is the kind of CSS framework people pick because they want speed, tiny bundles, and fewer moving parts. Good call. But once you start shipping a real app with analytics, fonts, icons, and maybe a little JavaScript sugar, your CSP usually turns into a weird mix of good intentions and emergency exceptions. I’ve seen this a lot: the app starts with a nice strict policy, then somebody adds a tag manager, then a consent banner, then inline styles sneak in, and now style-src 'unsafe-inline' is hanging around forever like a bad temporary fix. ...

Twind is great when you want Tailwind-style utilities without a build step. The CSP story is where things get annoying. The problem is simple: Twind often injects CSS at runtime using a <style> tag. CSP hates that unless you explicitly allow it. If you try to run Twind under a strict policy without planning for style injection, your app looks broken fast. This guide is the practical version: what breaks, what policy you need, and the least-painful ways to make Twind work. ...

Remix Icon is easy to drop into a project, which is exactly why people ship it with a sloppy CSP. I’ve seen this a lot: someone adds the Remix Icon CDN snippet, the icons don’t render, they get a wall of CSP errors, and the “fix” becomes style-src 'unsafe-inline' plus a couple of random hostnames copied from the console. That works, but it’s the kind of fix that quietly makes the policy worse every time the app changes. ...

Turret CSS is just CSS, so on paper CSP should be easy: allow your stylesheet, block the weird stuff, move on. In practice, teams still break production layouts with CSP all the time. I’ve seen the same pattern over and over: someone tightens style-src, the app ships, and suddenly Turret CSS “doesn’t work.” Usually Turret isn’t the problem. The policy is. More specifically, the policy was written with JavaScript in mind and nobody checked how styles are actually loaded, injected, or modified across the app. ...

I’ve seen the same pattern over and over: a team adopts a utility-first CSS framework, ships fast, then bolts on CSP later and wonders why the site breaks in weird places. Pharaoh CSS is no exception. The good news is that CSS-heavy sites are usually easier to lock down than JavaScript-heavy apps. The bad news is that most teams still start with a lazy policy like style-src 'unsafe-inline', leave it there forever, and call it “good enough”. It usually isn’t. ...

If you’re tuning CSS in production, you’ll usually end up doing two things: minifying with cssnano removing unused selectors with a purge step Those are build-time optimizations, so people assume CSP has nothing to do with them. That assumption bites later. CSP does not care that your CSS was generated by PostCSS, cssnano, Tailwind, PurgeCSS, or a custom pipeline. CSP only sees what the browser sees: where styles came from, whether they were inline, and whether some script injected them at runtime. ...