Repository navigation
Failed to find a valid digest in the 'integrity' #1231
Description
When i run the build command and upload my files to server this error appears in mobile browsers:
Failed to find a valid digest in the 'integrity' attribute for resource 'http://facilbardelivery.com.br/static/css/main.33fa5f7d.css' with computed SHA-256 integrity 'fhBe+EZQ6zPH/PQFiIlVZjwvoWQGAWe1s8BEyp2TJ6k='. The resource has been blocked.
Activity
gaearon commentedon Dec 10, 2016
As I noted in the other thread, have you followed these instructions?
Could that be the reason it is failing?
BrunoQuaresma commentedon Dec 10, 2016
Yes, I followed the instructions. In PC browser works fine (facilbardelivery.com.br) but in chrome(for android) not. However, when I test the app in Heroku (facilbar.herokuapp.com) with HTTPS it works even in mobile phone. So, is required use SSL?
gaearon commentedon Dec 10, 2016
Ugh. I think we’ll have to revert this change because I don’t know how to troubleshoot this.
Want to send a PR?
cc @XVincentX
XVincentX commentedon Dec 10, 2016
Let me dig into - subresource integrity does not require SSL at all.
Timer commentedon Dec 10, 2016
It sounds like the feature is simply doing what it's intended to do.
Do you have compression enabled in your Chrome for Android browser?
Google may be minifiying your CSS before sending it to your phone causing the signature to be invalid.
SSL prevents this from happening. Maybe we should look for https in PUBLIC_URL and toggle this feature based on that.
https://developer.chrome.com/multidevice/data-compression
Timer commentedon Dec 10, 2016
"The proxy performs intelligent compression and minification of HTML, JavaScript and CSS resources, which removes unnecessary whitespace, comments, and other metadata which is not essential to the rendering of the page. These optimizations, combined with mandatory gzip compression for all resources, can yield substantial bandwidth savings for the client."
BrunoQuaresma commentedon Dec 10, 2016
@Timer this is it!!! Thanks! When i disable it works perfectly.
XVincentX commentedon Dec 10, 2016
That might eventually change the received file which is seen as a resource tampering from the browser.
This is not happening on mobile Safari (just tested on my iPhone)
BrunoQuaresma commentedon Dec 10, 2016
I think in this mode it does a proxy cache that even with the digest is not invalidated.
Even after activating again. The page continues to display correctly.
Timer commentedon Dec 10, 2016
Actually we could inject a stub which strips resource validation when over HTTP.
I'd be more than happy to make a PR if that's what we decide to do.
Currently, this feature is going to cause more pain than benefit because of Chrome compression or ISP compression if they partake in it.
We need to do something about it (opt in?) or revert it for now.
gaearon commentedon Dec 10, 2016
How would this work? I’d like to see a proof of concept.
Either that or let’s roll it back.
XVincentX commentedon Dec 10, 2016
That's sad, but I understand that it's blocking and annoying :(
Timer commentedon Dec 11, 2016
Sorry I was speaking in mere hypotheticals; it's not something I have done before.
But the idea would be to check
window.location.protocolfor https, if not found, scrub the script tags (and css; anything I guess) on the document and removeintegrityattributes.In theory we would inject a script tag before the bundle script tag, and add the
deferattribute to them both.This would allow both script tags to be loaded into the DOM before any execution; which in theory would allow us to manipulate the attributes on the second script tag since the script tags should be eval'd synchronously and in order.
^ sound crazy enough to work?
2 remaining items
Timer commentedon Dec 11, 2016
😢 PR #1233
gaearon commentedon Dec 11, 2016
Closing via #1233, please feel free to open new issues / PRs if you have ideas on how to add this back.
gaearon commentedon Dec 11, 2016
Should be fixed in
react-scripts@0.8.4. Please verify.https://github.com/facebookincubator/create-react-app/releases/tag/v0.8.4
jscheid commentedon Dec 11, 2016
😢
I'm going to add language to our README to clarify this point, current draft is here:
waysact/webpack-subresource-integrity#25
See also https://bugs.chromium.org/p/chromium/issues/detail?id=642928
Timer commentedon Dec 11, 2016
Cool, @jscheid! I was not aware of this.
jscheid commentedon Dec 12, 2016
@Timer It's a clever hack! :-) Unfortunately, inline scripts don't play nice with CSP, and conceivably there's a large overlap between folks who'd want to use SRI and those who'd want to add a CSP.
Theoretically it's possible to white-list inline scripts with CSP, but that's not exactly straightforward. I think at that point you're better off just setting
Cache-Control: no-transform.Of course, with a non-inline script it becomes a catch 22 if you do use SRI for it, and Achilles' heel if you don't :-/ Not to mention the extra HTTP request.
There's also potential issues for people with JS disabled or ad blockers, considering that SRI also affects CSS loading. I believe CSP is already a show-stopper here so probably not worth elaborating on this.
jscheid commentedon Dec 12, 2016
For the record, I wasn't aware of this problem either before today or I would have let you guys know. (When I said "clarify this point" above, perhaps it made it sound like I knew about this before, but I didn't.)
gaearon commentedon Dec 12, 2016
Yea no worries. Today we learned. :-)
XVincentX commentedon Dec 12, 2016
Me too - I didn't really think there were so many consequences.
kornelski commentedon Jun 27, 2017
I've tested compression proxies a while ago, and they all respected
Cache-control: no-transform(I've focused on images, but scripts are compressed by the same products).tasn commentedon Dec 28, 2017
Given the prevalence of https, is this even still an issue? I'm happy to do the work needed to make it an opt-in if someone could direct me to an example of how an opt-in feature looks like in create-react-app or what is the recommended way of doing it.
I recently created a browser plugin that verifies the pgp signature of a page. It relies on subresource-integrity to also validate external scripts and styles.
I need it for the EteSync web app (uses react-based web app), and I'd rather not eject just to add this.
tasn commentedon Dec 28, 2017
Furthermore, one way of fixing those applications that break because of subresource integrity is just make them change the resource uri scheme from "://" to "https://", making sure that subresources are always loaded from an encrypted source and thus won't be mangled by evil proxies.