Name one owner, usually engineering with marketing as the requester, and give them a routine: detect the change, review the new file, regenerate the hash, test, then release. Without a named owner, an integrity hash either blocks a working tag or gets removed to stop the complaints.
Why the hash breaks on purpose
MDN describes Subresource Integrity as a cryptographic hash that a fetched resource must match. If the file differs by even one byte, the browser refuses to load it and returns a network error.
That is the point, since it stops a tampered file from running. It also means a legitimate vendor update looks the same as an attack to the browser. The OWASP cheat sheet warns of this directly: you can get secure but not working third-party code when the vendor decides to update it, so monitor vendor JavaScript for changes on a regular basis.
On a store, the cost shows up quickly. If the broken tag is a payment widget or a conversion script, someone notices within hours, and the pressure is to delete the integrity attribute.
The hidden requirement: a pinned file
SRI only works on a file that does not change. If the vendor serves a URL that always returns the latest build, a hash will break on every release. You need a versioned URL, or a copy you host yourself, so that the content only changes when you decide.
Cross-origin use also needs CORS. MDN explains that the vendor server must send an Access-Control-Allow-Origin header, and that your script tag needs the crossorigin attribute. Check both before you roll out hashes.
A routine that works
- Detect. Fetch each pinned vendor file on a schedule and compare its hash with the one in your code. A mismatch opens a ticket.
- Read the change. Diff the old and new file where possible. Minified code is hard to read, so ask the vendor for release notes and look for new domains the script contacts.
- Ask the vendor. If the change was not announced, treat it as unplanned and ask them to confirm it.
- Regenerate. Compute the new hash, update the tag and the version in your tag register.
- Test. Run the page flows that use the tag on staging, including checkout where relevant.
- Release. Ship through normal change control, and keep the old hash for a fast rollback.
Who does what
| Step | Owner | Support |
|---|---|---|
| Detection job | Engineering | Security |
| Reading the change | Engineering | Vendor contact |
| Business sign-off | Marketing or product | None |
| Release | Engineering | QA |
Marketing should know the routine exists and what it costs in time. OWASP calls the wider discipline MarSecOps: the marketing team, the vendor and operations exchanging information so that hash changes and page changes stay in step.
Plan around peak periods
Agree with vendors that they will not push unannounced changes in your busiest weeks, and align your freeze dates with theirs. If you have a peak season dependency freeze plan, add pinned vendor files to it.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how ongoing checks surface a change after the day you first reviewed something.
Where Safeguard fits
For packages in your build, Safeguard's policies and gates can block a pull request that breaks a rule you set, and its SBOM and dependency scanning records what you ship. Script files served by vendors at run time sit outside that, so keep the routine above. A free scan is at gold.safeguard.sh/scan.
Quick check
Should we remove SRI when a hash keeps breaking?
No. Fix the cause, which is usually a floating URL. Pin a version or host the file yourself, then add the hash back.
Does SRI need the vendor's cooperation?
Yes for CORS headers on cross-origin files. Check that the vendor sends them before you rely on the hash.
Sources
Last reviewed: 19 October 2026.
