Critical CSS

Non-starter for all but hobby websites since it's incompatible with any content security policy disallowing inline style tags.

Edit regarding replies to this comment: I'm sure many will get a kick out of your workarounds and they're all worth posting in the spirit of HN, however I am talking about CSPs that disallow shenanigans. Carry on though :^)

That’s a good point, though can’t this instance be whitelisted with a nonce?

You can allow safe inline CSS with a nonce. For example:

  <style nonce="sha256-Ce2SAZQd/zkqF/eKoRIUmEqKy31enl1LPzhnYs3Zb/I=">
    html { background: red }
  </style>

And a CSP like this

  default-src 'self'; style-src 'sha256-Ce2SAZQd/zkqF/eKoRIUmEqKy31enl1LPzhnYs3Zb/I='

Here's how I automate mine:

https://github.com/uxtely/js-utils/blob/ad7d9531e108403a4146...

You could, but in the real world not every frontend dev has control over the CSP on the server allowing nonces to even be an option.

Even when they do they might be subject to a security audit forbidding it. There's two reasons nonces can suck: first is that nonces may be passed around for 3rd party script usage and that blows a hole in your security policy, and the other is that many implementations to generate nonces are not implemented correctly, so the security team might have less trust in devs.

It really depends on the organization and project. Once you start getting near the security fence you may find it's more trouble than it's worth.

I would try to find less complicated solutions for small details like this. Obvious question might be why your CSS can't be a separate file that is small enough to not cause a performance issue.

Its completely compatible, if you separate dynamic content until after the critical css is loaded: https://posts.summerti.me/being-unsafe-safely/

> content security policy disallowing inline style tags

Wait, why on earth is this a thing?

I guess the main case is if user-generated content has an escape bug that lets the user inject a <style> tag?

If only this was about UGC. Most of it can have nothing to do with actual users. Think stuff like ads or other injects like a dependency of dependency of dependency of your frontend app compromised by a north korean hacker.

The threats solved by restricting CSS with CSP are pretty minor, but generally its to prevent injection attacks that do the following:

- injecting css to restyle the page as part of a social engineering attack or to otherwise trick the user into doing something stupid

- using css to load an image or something to track users viewing the page or capture their IP address

- leak the values of attributes on the page (you can do complex things with ^= and ~= selectors to leak attribute values). Sometimes page text contents can also be leaked using tricks with fonts and scrollbars (not sure if that still works on modern browsers).

On the whole though, the surface area is small compared to javascript. I often see people restrict css before js (or doing the js restrictions incorrectly) because restricting css is much easier, but that is really silly as an attacker will always reach for javascript first if its available.