Subresource integrity

A third-party host being compromised and serving a modified file to your visitors.

A content delivery network account being taken over and its contents replaced.

A file silently changing under a version label that was supposed to be immutable.

It does not protect against a third party deliberately shipping something harmful in a new version, because you would update the hash along with the version.

The hash describes one exact file. Any change — a patch release, a whitespace edit, a rebuild — produces a different hash and the browser refuses the file.

So it is incompatible with a URL that always serves the latest version, which is exactly the URL shape convenience encourages.

That is a feature rather than a limitation: a URL that can change under you is one you cannot verify by definition.

The practical pattern is pinning an exact version, recording its hash, and updating both together as one deliberate change.

When verification fails, the browser does not load the file. A script that provides a feature silently stops providing it.

Which means a mismatch caused by a routine third-party update looks identical to a mismatch caused by a compromise, from the visitor's side.

A crossorigin attribute is required alongside for cross-origin files, because without it the browser cannot read the response to verify it.

That pairing is the most common implementation mistake: the integrity attribute is present, the crossorigin attribute is not, and the file is blocked on every load.

Files from a third-party host that are on every page, particularly anything running before the rest of the page.

Not first-party files from your own infrastructure, where a compromise means the attacker could change the hash too.

Not files whose URL you do not control the versioning of, since they will break on the next update.

A content security policy covers the adjacent question of which origins may load scripts at all, and the two are complementary rather than alternatives.

The hash is taken over the exact bytes of the file and encoded, prefixed with the algorithm that produced it.

Several hashes may be declared for one file, and the browser accepts a match against any of them — which is how two versions can be permitted during a rollout.

Most package registries and content networks publish the value alongside the file, so it rarely has to be computed by hand.

A hash computed from a local copy is only correct if that copy is byte-identical to what the host serves, which a trailing newline is enough to break.