Closed joergbaier closed 2 years ago
The most likely explanation, based on your description, is that index.html gets cached and is stale. Have you had a look at it yet (using the DOM inspector in FF) to see if the hash on the script tag is what you'd expect?
Or it could be an extension. If you have any installed, make sure they're all disabled.
The index.html is fresh (we are sending cache-control: no-store) and can see that a full network request is occurring to fetch that file. The script source and integrity are up to date.
I've disabled extensions and getting the same error.
Curious. If you can absolutely rule out caching, proxies, extensions, service workers, (malicious actors 😄) -- anything that could mess with the responses/contents -- (maybe try a fresh install on a different machine just to be sure) then you may have hit a bug? Perhaps one that only gets triggered in certain edge cases, possibly to do with the CSP and/or your use of modules? It's not inconceivable, years ago Chrome had a bug in their SRI handling for example (to do with charset encodings, if memory serves.)
You could try an older FF version, or consider installing it from source to see if you can get any debug output out of it.
Thanks for the leads, I'll try a few more CSP/no-CSP & ServiceWorker/no-ServiceWorker combinations and report back in a day or two ... last resort I'll try the FF from source 😅
I believe the issue is narrowed down to this combination:
While this is not necessarily an issue with webpack-subresource-integrity, people here may be the most helpful with our issue.
When using the Angular subresource-integrity build option, several script tags are injected into the index.html like the one below:
Our S3+CloudFront hosted Angular application will initialize in Chrome and Safari, but not Firefox due to the following error:
The generated sha384 from https://www.srihash.org/ matches. The downloaded script by Firefox has identical contents to other browsers and curl. Caching doesn't seem to be an issue either, I've tried private windows and clearing all cached data.
I downloaded the remote index.html, replaced
src="runtime.cdc6837cf654de44.js"
withsrc="https://_our_domain_/runtime.cdc6837cf654de44.js"
and then opened this local file in Firefox, which works, the application will initialize. This makes me think that Firefox handles "same-origin" differently.Any ideas why Firefox errors out?
Why are we using subresource-integrity?
We are trying to add a strict csp policy that uses strict-dynamic. Using hashes greatly reduces the complications of hosting our SPA vs being nonce based.