Subresource Integrity: reliably recognise expected files

Which trust SRI limits

HTTPS secures transport to the server being contacted. It does not prevent that server itself from returning a changed file. SRI can detect that change if the expected hash in your HTML or the relevant integrity configuration remains unchanged. If an attacker can replace that metadata too, the control is defeated at this point.

SRI is particularly suitable for reviewed, versioned static files. Same-origin files can also be checked; here, consider whether the file and its metadata have separate trust boundaries at all. The subsequent comparison does not protect against a compromised dependency already present in the build before hashing. W3C SRI: goals and security limits

The Web Security Check performs a limited examination of the final response's static HTML: recognisable external scripts and stylesheets, integrity metadata and CORS loading mode. It does not download the files to compare hashes or perform a complete inventory of dynamically loaded resources. ‘Metadata present’ therefore does not establish a successful content comparison.

From reviewed bytes to browser comparison

The sequence has three steps: you identify a reviewed file and generate its hash. The browser loads the referenced resource. It compares its content using the valid metadata; if it differs, the resource is not used. Even when it matches, other requirements such as CSP, MIME type and CORS must still be satisfied.

Several supported algorithms do not mean ‘any one will do’: the strongest supported algorithm present determines the comparison. Multiple hashes using that same strongest algorithm can permit alternative contents. Unknown algorithms are ignored; if no recognised metadata remains, there is no integrity check. The mere presence of an attribute is therefore insufficient evidence. SRI §§ 3.2–3.3

Generate a hash from the reviewed file

Generate the hash from the exact approved artefact that will later be served. Blindly hashing a third-party response just downloaded would also pin an already compromised version. A deliberate update therefore requires source provenance, version review and functional testing before approval.

The following complete example uses only a synthetic local file. The first line creates sri-demo.js in the current working directory; use an empty test folder:

printf 'window.sriLoaded = true;\n' > sri-demo.js
openssl dgst -sha384 -binary sri-demo.js | openssl base64 -A

For exactly these bytes, including the newline, the integrity attribute is:

<script src="/assets/sri-demo.js"
  integrity="sha384-V7pNkAZ7iDlrSXBjbzvgfRGvaRgOebq8zZnoQerOZvWviUZKtNamq8+edcPrWG67"></script>

The URL must actually serve this file; the example does not install a resource. For a classic script from another origin, crossorigin="anonymous" is usually added. The external server must allow suitable CORS access. For public anonymous delivery, this can be Access-Control-Allow-Origin: *. Module scripts already use CORS mode; a missing crossorigin attribute there is not an error on its own.

A build can generate hashes and references together. Whether a particular plugin also covers subsequently loaded chunks, styles, preloads and module dependencies must be checked in its actual output. There is no universal promise that ‘all assets are covered automatically’. Online generators are unnecessary for this process and do not replace checking the input data.

Which resources and changes are covered

SRI does not provide a general integrity attribute for every HTML element. Typical uses are external scripts and stylesheet links; HTML also defines suitable loading paths such as preloads, and Fetch has an integrity option. Images, videos and iframe documents are not checked merely because you add an arbitrary integrity attribute. SRI §§ 3.4–3.6

Dynamic responses do not make the comparison ineffective: different bytes still fail. However, they complicate maintaining all intended variants. Examples include personalised widgets, automatically changing analytics scripts or responses that depend on browser and region. In those cases, choose a stable approved endpoint, a permitted version you manage yourself or another verified integration strategy. Remove a service if the trust it still requires does not suit your needs.

SRI can also provide an additional boundary for your own scripts, provided the attacker cannot change the metadata at the same time. A blanket exemption for all same-origin files would therefore be just as wrong as promising that SRI protects against a complete server compromise.

Updates, errors and rollback

Use stable versioned or content-based addresses. Publish new files before the HTML or import-map references, and retain old artefacts for as long as cached documents still reference them. Hash, version and file belong in the same approval process; Cache-Control affects the transition.

Check at least the expected file, a locally modified variant and missing CORS permission. The valid case must work; the tampered version must not execute. A resource error alone does not identify the cause: network, MIME, CORS, CSP and SRI can all prevent use. The browser console and network response help narrow it down.

A fallback can load a separately trusted local copy of the same approved version. After an SRI error, it must not include the same external file again without checking it. An error handler must also be registered before loading fails; inline handlers may be blocked by your CSP. A fallback therefore belongs in tested application code, not as an untested universal copy-and-paste pattern on every page.

If unexpected blocking occurs, return to the previous known pair of file and metadata, or disable the affected function in a controlled way. Removing checksums without understanding the delivered change removes the intended control. Recalculating the hash alone does not investigate the cause.

Protect module dependencies individually

An entry module's hash does not automatically cover its imports. An import map can store separate integrity metadata for each module URL. Entries must be available before the affected loading takes place and explicitly cover every intended direct, transitive and dynamic import. A single entry does not cover the entire dependency tree. HTML: import-map processing

This schematic example is deliberately not executable: replace each descriptive hash placeholder with the digest of the corresponding reviewed file.

<script type="importmap">
{
  "imports": { "bibliothek": "/assets/bibliothek.v1.js" },
  "integrity": {
    "/assets/bibliothek.v1.js": "sha384-DIGEST_DER_BIBLIOTHEK",
    "/assets/helfer.v1.js": "sha384-DIGEST_DES_HELFERS"
  }
}
</script>

The implementation data read on 27 September 2026 lists the integrity field from Chrome 127, Safari 18 and Firefox 138. This differs from the earlier support for basic import maps. The local Chromium 147 test documented at that time showed both a changed child import loaded without checking and its blocking when given a separate integrity entry. Other target browsers and your build still require their own checks.

A document-wide requirement for integrity metadata through Integrity-Policy is a newer mechanism with its own support status. It is not equivalent to the established comparison of individual resources; see further headers.

Integrity is only part of supply chain security

SRI establishes neither a script's authorisation nor its business necessity, safety or complete coverage. For payment pages, distinguish the technical integrity control from the applicable PCI DSS assessment scope. Even the PCI SSC explanation concerning 3DS scripts includes specific conditions on applicability; it is not a general exemption for arbitrary payment scripts.

An SRI finding likewise does not establish NIS2 compliance. Inventory, secure sources, update maintenance, protected builds and the behaviour of permitted code remain separate tasks. Compliance overview