Pin and review the intended resource, verify the exact bytes and cross-origin prerequisites, then release the URL and integrity metadata together.
Subresource Integrity compares a supported external resource with expected content hashes and blocks it when the bytes do not match. If a supplier intentionally changes a script, an old hash can therefore stop the updated file from loading. The safe repair is to review and release the intended resource and its metadata together, not remove integrity checking until the page appears to work.
Choose a resource whose expected contents you can maintain. A constantly changing unversioned loader and a stable versioned library present different operational problems. SRI is one narrowly defined control, rather than a full audit of everything a supplier’s code does.
Confirm that integrity is the failing boundary
Reproduce the affected journey in an authorized preview. Inspect the browser’s Console and Network evidence for the specific resource, final URL, response status and integrity error. A missing script can also result from a network failure, content policy or an unexpected response such as an HTML error page.
Record the script’s insertion point: template, app, plugin, tag manager or build output. Find the owner who can update the resource URL and integrity attribute together. Editing only one rendered instance while another system regenerates it creates a recurring mismatch.
The Console and Network guide helps collect that evidence. Keep private request data out of screenshots. Do not paste a vendor credential or account-bearing script URL into a public hashing tool.
Understand what the hash approves
MDN describes integrity metadata as cryptographic content hashes and explains that a mismatch makes loading fail. Matching means the resource matches expected contents; it does not mean those contents were independently reviewed for every security, performance or privacy concern.
Whitespace, generated banners and different file builds can change the expected content. A minified release and an unminified release are not interchangeable just because both carry the same library version. Treat the exact resource identity as part of the release record.
When several hash algorithms are present, MDN documents selection using the strongest supported algorithm represented in the metadata. Do not add random alternative hashes hoping one will make a changing file work. Every accepted version should be intentional and accounted for.
| Observed condition | What to check | Safe response |
|---|---|---|
| Same URL now delivers changed contents | Supplier release policy and reviewed version | Approve a specific intended build or use a supported versioned route |
| Different resource URL with an old hash | Deployment pairing | Release matching URL and metadata together |
| Cross-origin resource lacks suitable CORS support | Request mode and response headers | Use the supported integration; do not bypass browser checks |
| Hash matches but the feature fails | Dependencies, API changes and initialization | Investigate compatibility separately |
| Loaded script requests additional code | The complete dependency graph | Review those resources under their own controls |
A fictional version update
A fictional publisher uses a versioned chart library. A preview changes its URL from one approved version to a newer release but retains the old integrity metadata. The browser refuses the file, and charts disappear while the surrounding article remains readable.
The maintainer confirms the new release’s intended source and build, reviews its changes and calculates metadata from the approved resource using a trusted local or documented build tool. The maintainer updates the URL and hash as one change, then checks a representative chart, keyboard use and the unavailable-library fallback in preview.
If the newer release breaks an initialization option, a matching hash will not repair that compatibility problem. The maintainer either resolves the supported integration or rolls back the paired resource and metadata. This example is fictional; no browser or library outcome is claimed as measured here.
Cross-origin checks are part of the setup
The W3C SRI specification requires CORS for cross-origin integrity use. The page’s request must use a compatible mode and the resource server must supply the relevant permission. The integrity attribute cannot independently authorize reading a resource that does not support the necessary cross-origin exchange.
Ask the supplier whether its supported resource endpoint fits that model. A conventional anonymous cross-origin integration differs from a credential-bearing private response. Do not apply one copied configuration to both without understanding the response contract.
The CORS diagnosis guide covers permission failures separately. Avoid disabling browser protection, proxying private code through an unrelated public service or returning broad credentials permissions just to hide an SRI failure.
Design the update process before the next change
OWASP’s third-party JavaScript guidance treats integrity and updates as operational responsibilities. For each pinned dependency, assign who reviews new releases, where approved artifacts come from, how hashes are produced and how rollback works. An abandoned hash can leave an essential component unavailable; an automatically accepted hash can approve a change no one reviewed.
Keep resource identity, release notes, expected metadata and dependent initialization in the same review. If your system generates the HTML, let its supported build process maintain the pair. Avoid manual production edits that will disappear at the next deployment.
A hash on the initial script does not automatically approve every later resource it loads. Review that dependency graph through the third-party scripts and embeds audit. Likewise, SRI does not isolate approved code from the page’s privileges or replace an appropriate content policy.
Accept the update with useful failure behavior
- Confirm the approved final URL and exact resource contents.
- Check matching metadata and applicable cross-origin support in preview.
- Complete the reader task that depends on the script.
- Exercise a controlled unavailable-resource case and inspect the fallback.
- Verify rollback restores the previous resource and metadata together.
- Record the owner and next review trigger.
For a nonessential chart, retain an understandable explanation or data alternative if its library fails. For an essential workflow, provide an honest error and a supported continuation route rather than pretending success. Your next step is to identify one currently unowned integrity-protected dependency and document its update contract before its next release.
Coordinate caches with the paired release
A deployment can leave old HTML referring to one script version while a mutable URL begins serving another. Before release, identify which files are versioned and which responses are cached. A rollback that changes only the hash can create the opposite mismatch for another visitor.
Prefer an update plan in which previously published resource URLs retain their approved contents while new HTML points to the reviewed replacement. Where a supplier cannot provide that contract, document the supported alternative and operational cost. Test a fresh visit and a representative returning visit in preview. This checks release compatibility rather than merely comparing one downloaded file on the maintainer’s computer.
Sources and verification
Editorial review 2026-10-17. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- W3C: Subresource IntegrityChecked Integrity metadata, supported subresources and cross-origin CORS requirement.
Limits: Specification is not a security review of the approved bytes. - MDN: Subresource IntegrityChecked Content hashes, algorithm selection, blocking and CORS use.
Limits: Browser behavior and supported deployment need verification in the actual site. - OWASP: Third-party JavaScript ManagementChecked Operational ownership and integrity/update coordination for third-party scripts.
Limits: SRI does not isolate approved code or monitor all subsequently loaded resources.