Subresource Integrity and CDN scripts
Loading a JavaScript library from a CDN means trusting that third-party server to never serve a file different from the one that was tested; the `integrity` attribute, part of the W3C Subresource Integrity specification, removes that blind trust by comparing a hash calculated in advance against the hash of the file that actually arrives in the browser.
A 384-bit digest in base64 always comes out to 64 characters after the algorithm prefix; it is the size most CDNs (jsDelivr, cdnjs) already hand out ready-made next to the file link.
All three hashes come from the same file, so any one of the three protects equally against tampering; SHA-512's longer output does not mean more practical protection here, it just reflects the larger digest size, 512 bits versus 256.
For a stylesheet the generator builds a `<link>` tag instead of a `<script>` one, but the rule is the same: without `crossorigin="anonymous"` on a different origin, the browser cannot read the bytes to check the hash and refuses to apply the CSS.
It is a browser mechanism that validates the integrity of scripts and styles loaded from other origins. The HTML declares the expected hash in the integrity attribute, and the browser rejects the resource if the content does not match.
Because without `crossorigin="anonymous"` on an origin different from the page's own, the response arrives opaque under CORS rules, and an opaque response does not expose its bytes for the browser to compute any hash; the integrity check has no way to happen, so the resource is refused regardless of whether the hash is actually correct.
Yes. `integrity` locks the exact file at that URL at the moment the hash was generated; if the CDN publishes a new version at the same address, or fixes a bug in the file, the hash changes and the page stops loading the resource until `integrity` is recalculated for the new content.
All three protect equally against file tampering, because any single-byte change already alters the resulting hash under all of them; SHA-384 is the most common choice because it is what most CDN hash generators offer by default, not because SHA-256 is unsafe for this use.
It does, but the `crossorigin` attribute stops being necessary when the resource shares the page's own origin, since there is no CORS restriction to work around; `integrity` alone already guarantees the browser rejects the script if the local file changes without the hash being updated.
———The snippet shows up hereThe hash is computed only in the browser with WebCrypto. The content and file are never sent to any server. The URL is used only to build the snippet, never fetched.