Hash-based CSP support
See original GitHub issueShout 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.
Issue Analytics
- State:
- Created 5 years ago
- Reactions:5
- Comments:16 (1 by maintainers)
Top GitHub Comments
Interesting approach @onpaws . Curious if anyone knows of other solutions for using jss in environments where dynamically rendering html tag content is not an option (e.g. when serving from a CDN). Currently, I’m setting
style-src 'unsafe-inline'
as a policy, which isn’t ideal.I did find that dynamically rendering the
<meta property="csp-nonce" content="{{ styleNonce }}">
tag on the client works, assuming the page already has one or more nonces for inline styles, which is super surprising. E.g.Doesn’t that kind of undermine the whole point of CSP rules and nonces? I.e. if malicious code on the client can read the existing nonces, what point does it serve? Presumably if something can inject malicious css, it can also read the existing nonce and convince the browser to interpret the css? Or am I missing something here?
@onpaws I’m pretty sure new <style> tags need to follow the CSP, but if js adds
<element style="">
after the initial load then that style should be applied.