- Use a versioned script URL and generate an integrity value from the exact bytes you plan to ship.
- For a cross-origin file, add
crossorigin="anonymous"and confirm the host returns a suitable CORS header. - Treat a hash change as a release decision. Test the failure path before enforcing Integrity Policy.
A script from a trusted CDN can change without your page changing. If that file is replaced, every visitor may run the new bytes.
Subresource Integrity, or SRI, gives the browser an expected cryptographic hash. The browser fetches the resource, calculates its hash and refuses to use it when the values do not match.
That turns third-party script drift into a visible load failure. It does not make the dependency safe, so the release process still needs ownership and review.
Pin a version before you pin a hash
Start with a stable, versioned URL. A path such as /library/4.2.1/library.min.js states which release you expect. A moving path such as /latest/library.js fights the hash: its purpose is to change while the integrity value says the bytes must stay fixed.
Download the exact production file through your normal build or release path. Generate a SHA-384 value from those bytes, then place it in the element's integrity attribute.
<script
src="https://cdn.example/library/4.2.1/library.min.js"
integrity="sha384-BASE64_DIGEST"
crossorigin="anonymous"></script>The digest above is a labelled placeholder, not a working value. Create it from your own file. Even a small byte change produces another digest.
SRI also works with supported link resources, including stylesheets, preload and modulepreload. Keep the file URL, hash and release record together.
Make cross-origin delivery pass CORS too
A cross-origin resource protected by SRI must pass the browser's CORS check. Add crossorigin="anonymous" to the markup, and confirm the resource host returns an Access-Control-Allow-Origin value that permits the page.
Check the real response, including redirects. A CDN example can be correct while a regional edge or redirect target omits the header. The browser then blocks the file even if the hash is right.
Self-hosting can reduce this coordination problem, but it also makes your team responsible for the copy, cache policy and updates. Use the vendor evidence checklist to decide who owns notices and recovery.
Plan an update as two approved hashes
The integrity value can hold several hashes. When several supported hashes use the same algorithm, a match with any one of them can approve the file.
This supports a short transition when a CDN may serve either of two known versions. Generate both values from reviewed files. Do not add a second hash for bytes you have not inspected.
| Change | Expected action | Release proof |
|---|---|---|
| URL changes, bytes change | Review file and replace hash | New version and digest recorded |
| URL stays, bytes change | Stop and explain the drift | Owner approves or restores content |
| CORS header changes | Fix host or self-host | Real response passes in target browsers |
| Hash mismatch | Fail closed for that resource | Page remains safe and understandable |
Do not delete the integrity attribute during an incident. That would run unverified bytes just when trust is uncertain.
Add policy only after the markup is ready
Integrity-Policy is a newer response header. It can require integrity data for script or style requests. The report-only form logs a violation without blocking the file.
Do not make it your only control. The W3C document is still a working draft, and MDN marks the header as limited availability. Keep explicit integrity attributes as the base.
Where browsers support the header, start with reports. Look for dynamic loaders, injected widgets and resources fetched in no-cors mode. Block only after the pages you checked are clean.
Keep CSP and SRI in separate roles
A Content Security Policy can restrict which origins may supply scripts. SRI checks the bytes of one chosen file. They solve different problems.
SRI also does not protect the HTML document that contains the hash. If an attacker can rewrite that page, they may change both the script URL and integrity value. Protect deployment access, use HTTPS and review the package release path that produces the file.
A service worker can add another cache layer. The service-worker rollback guide helps separate an asset update from the time clients actually receive it.
Test the blocked state before release
- Load the approved file. Confirm the script runs and the browser shows no integrity or CORS error.
- Change one test byte. Keep the old hash and confirm the browser refuses the resource.
- Remove CORS in a test path. Confirm a cross-origin load fails even with the right digest.
- Check page behavior. The site should not expose a broken purchase or sign-in action when a nonessential script fails.
- Exercise the update. Review the new file, generate its digest, deploy markup and resource in a controlled order, then remove the old hash.
These are procedures for your team to run. TechWeb did not test your CDN, scripts, headers, browsers or deployment pipeline.
Frequently asked questions
Does SRI stop every script supply-chain attack?
No. It checks fetched bytes against approved hashes. It does not prove that the approved dependency is safe or protect HTML that an attacker can rewrite.
Why does a cross-origin SRI script need crossorigin?
The browser must use CORS for this check. The resource host must also return a header that permits access.
Can I use SRI with a latest-version URL?
Yes, but the next byte change will fail. A versioned URL gives the update a clearer path.
Should I enforce Integrity-Policy today?
Start with explicit integrity attributes. Where the header is supported, use report-only first and confirm compatibility before blocking.
Sources
W3C: Subresource Integrity · MDN: Subresource Integrity · MDN: Integrity-Policy. Browser and header support can change; verify the current compatibility data before enforcement.
More in this sectionTechnology →