Jss: Hash-based CSP support

[onpaws]

Shout out to the lovely humans who did some great CSP work so far and even shipped documentation. I was recently able to get CSP working on my project thanks to this, cheers.

So this is a great start, but because my app is 100% static [1] I'd prefer to calculate everything ahead of time and avoid the dynamic nonce injection/Helmet approach, if possible. In other words I'd like to support this CSP flavor - do a search for _hash-algorithm_.

Thus I'm now trying to understand the basis by which JSS injects these <style> tags, e.g.

First I thought if it were possible to force JSS to inject a single <style> tag into the document, I could hash that ahead of time. Then I read the material-ui docs which discuss performance reasons for splitting styles across multiple tags, and now I'm curious to learn about the tradeoffs and configurability here.

A possible but clunky alternative is that according the Google CSP evaluator we can define multiple hashes inside one style-src string.
style-src 'self' 'sha256-z124...' 'sha256-2g7e...';

Perhaps this is all a terrible idea and that's OK. Still, even if academic, I'd love to learn what it'd take to arrange this. Hope I'm making sense and thanks for a lovely library either way!

[1] My app is based on CRA and doesn't need to support user-uploaded stuff -- in theory, we should be able to keep everything static, which will enable "dumb" CDN hosting -- fastest page loads at the lowest possible cost.

[onpaws]

Ok, in doing some initial poking around I see insertRule is where this appears to happen.
Now trying to zoom out a bit and better understand how/when this gets invoked at runtime...

[onpaws]

Curious if anyone is willing to voice opinions on this?

I find this idea appealing, because it would allow decoupling the otherwise static FE bundle from depending on dynamic nonce injection.

That's nice because that re-opens the door to CDN based hosting.

[HenriBeck]

If you are willing to create a PR for this, we would be open for it.
I or @kof don't have the time right now to look at this feature.

You would need to implement it, create tests and the documentation for it.

I guess the implementation should be relatively easy, though this approach wouldn't work where a StyleSheet is linked (dynamic). Also, your implementation shouldn't include any hashing libaries by default; the user would need to be able to pass/configure them, so they aren't installed for someone who doesn't use this feature.

[blowsie]

This might be of some use to you
https://github.com/slackhq/csp-html-webpack-plugin

[onpaws]

Thanks for sharing that, will take a look.

Starting tomorrow I'm going to be away for approx. the next 2 weeks but intend to resume looking at this when I get back. If anyone has enough interest to take a crack meanwhile, that'd be great!

More when I'm back :)

[dav-is]

Unfortunately I don't think something like this is scalable. You would need to list a hash of every style block you add. The CSP header would become huge in a large application.

[onpaws]

Thanks @dav-is, yeah I was basically starting to reach the same conclusion.
It appears the CSP header approach presumes you have a limited amount of <style> tags.
One thing I'm curious about is _when_ the security policy is applied. In other words, do the style tags that get injected after page init still have to have CSP headers? Not sure but hope to find out