SRI Failed integrity metadata check for jquery 3.5.1


Is anyone getting a failed integrity metadata check when loading jquery 3.5.1 in Safari 13.1.1? I currently can’t load from with SRI sha512-bLT0Qm9VnAYZDflyKcBaQ2gg0hSYNQrJ8RilYldYQ1FxQYoCLtUjuuRuZo+fjqhx/qtq/1itJ0C2ejDxltZVFg==.

Error is Failed integrity metadata check. Content length: 89476, Expected content length: 89476, Expected metadata: sha256-CSXorXvZcTkaix6Yvo6HppcZGetbYMGWSFlBw8HfCJo=

A similar issue seems to appear with popper.js

Any ideas appreciated, thanks.


Hm, this seems really odd, that hash is definitely correct.

I’ve tested with on Firefox & Chrome, as well as on Safari 13.1 and everything seems to be working fine.

For what it’s worth, it looks like 13.1.2 is now available, could you try updating to that just in case Safari introduce a regression that’s been patched?

If not, does removing the SRI check allow the resource to load correctly? Could it be that you have something in your network that is modifying the contents of the response, resulting in the hash not matching?

Hi Matt,

Updating to Safari 13.1.2 didn’t fix the issue. What I observed is that I was using a SHA256 SRI instead of a SHA512. Copying the tag again from CDNJS gave me this SHA512 SRI instead. Now it is working. Not sure why the SRI would be different from a week ago.

Tom Foxwell

A few diagnosis steps I’ve just done on our end:

Checked that the asset has never changed, so the hash of the contents should’ve never changed:

cdnjs$ git log --oneline -- ajax/libs/jquery/3.5.1
4e07bb33605 Add jquery v3.5.1

Looking at the history of the SRI hash we offer for the file:

Originally: sha256-9/aliU8dGd2tb6OSsuzixeV4y/faTqgFtohetphbbj0=
Now: sha512-bLT0Qm9VnAYZDflyKcBaQ2gg0hSYNQrJ8RilYldYQ1FxQYoCLtUjuuRuZo+fjqhx/qtq/1itJ0C2ejDxltZVFg==

Looking at the error you’ve shared, the hash you had set was sha256-CSXorXvZcTkaix6Yvo6HppcZGetbYMGWSFlBw8HfCJo=.

This does not match the calculated sha256 hash we were offering: sha256-9/aliU8dGd2tb6OSsuzixeV4y/faTqgFtohetphbbj0=

I think this is likely the source of the issue, the SRI hash you were using was simply incorrect for the file.