Modern web pages rarely arrive from a single server. A page may pull its JavaScript framework from a public content delivery network, load a stylesheet from a vendor, or reuse a library hosted by another organization. That convenience can improve speed and reduce duplication, but it also creates a trust decision: the browser is about to run bytes supplied by a third party.
Subresource Integrity, usually shortened to SRI, gives the page a way to state exactly which bytes it expects. The browser verifies a cryptographic fingerprint before applying a stylesheet or executing a script. If the downloaded file does not match, the resource is blocked.
Why HTTPS is not enough
HTTPS protects a connection against interception and helps the browser authenticate the server it reached. It does not guarantee that a file hosted on that server is the same file a site owner reviewed last week. A content delivery account could be compromised, a storage bucket could be misconfigured, or a vendor could accidentally replace a versioned asset.
That distinction matters because third-party JavaScript runs with the privileges the page gives it. It can read and change page content, observe form fields, and make network requests. Our guide to the limits of HTTPS explains why a secure connection is only one part of web trust.
How the integrity attribute works
A developer calculates a cryptographic hash of the approved file and places it in the HTML element's integrity attribute. A script reference might include a value beginning with sha384-, followed by the encoded digest. Stylesheets can use the same mechanism on a link element.
When the browser receives the resource, it calculates its own digest using the named algorithm. A match means the bytes are exactly those represented by the page. A mismatch means something changed, whether through an attack, a broken deployment, or a harmless update that was not coordinated. The browser refuses to use the file.
The W3C Subresource Integrity specification defines this verification model. The MDN SRI guide provides practical syntax and browser behavior.
A hash is a precise contract
SRI is intentionally strict. Changing one character in a minified script produces a different digest. That makes silent replacement difficult, but it also means routine dependency updates require a new integrity value. A team cannot point to a moving “latest” file and expect a fixed hash to keep working.
Reliable deployments therefore pin a specific version, calculate the digest from the final distributed bytes, and update the URL and hash together. Build automation can check that the value in the page matches the artifact selected for release.
An integrity attribute may list more than one acceptable digest. This supports transitions and multiple recognized algorithms, but every accepted value should correspond to content the site owner has deliberately approved. Adding an unreviewed fallback weakens the contract.
Cross-origin resources need cooperation
For a resource fetched from another origin, integrity checking works with Cross-Origin Resource Sharing. The remote server must allow the requesting origin, often through an appropriate Access-Control-Allow-Origin response header, and the HTML element commonly uses a crossorigin attribute.
This requirement prevents integrity checks from becoming a side channel for reading protected cross-origin content. It also means a CDN must be configured correctly. If its CORS response is absent or incompatible, the browser can block the resource even when the hash itself is correct.
What SRI protects—and what it cannot
SRI is strongest for stable scripts and styles referenced directly by trusted HTML. It reduces the risk that an attacker who changes a hosted dependency can automatically compromise every page that loads it.
It does not protect a page if an attacker can alter the first-party HTML and replace both the resource and its hash. It also does not review what an approved script does. Malicious behavior already present in the expected file will pass verification perfectly.
Dynamic code creates another boundary. A verified bootstrap script may fetch modules, configuration, or data at runtime. Those later requests are not automatically covered by the original element's integrity value. Teams must understand the whole dependency chain rather than treating one successful check as a blanket guarantee.
Use SRI with a layered policy
A strong deployment combines SRI with a restrictive Content Security Policy. CSP controls where resources may come from and can limit inline code. SRI verifies the exact content of selected external files. Together, source restriction and byte-level verification address different failure modes.
Version pinning, lockfiles, dependency review, self-hosting where appropriate, and monitoring for failed resource loads all remain useful. Our guide to browser extension update security explores the related principle that trusted software changes need a verifiable delivery path.
A practical rollout checklist
- Inventory externally hosted scripts and styles, starting with code that reaches sensitive pages.
- Replace floating or “latest” URLs with explicit, immutable versions.
- Generate hashes from the exact production files, not an earlier build artifact.
- Confirm the provider returns suitable CORS headers for cross-origin resources.
- Test failure behavior so an unavailable dependency does not leave security controls or essential forms in a dangerous partial state.
- Update the resource version and integrity metadata in the same reviewed change.
- Monitor browser console and reporting data for unexpected integrity failures.
Subresource Integrity makes a narrow but valuable promise. It does not decide whether a dependency is trustworthy; it lets a website name the dependency it trusted and asks the browser to reject anything different. On a web built from shared components, that exactness is a useful line of defense.
Browse with more intention
Noorani brings prayer times, Qibla, tracker blocking, and privacy into one calm desktop browser built for how Muslims live online.