Identify the file that can be pinned
A browser loading an external script gives that file considerable influence over the page. If a supplier or distribution endpoint changes the bytes at a URL, the shop may receive code it did not review even though its own deployment has not changed. Subresource Integrity, or SRI, attaches an approved cryptographic digest to a script or stylesheet element. The browser calculates a digest of the fetched resource and refuses a mismatch. This is valuable for a versioned, stable external library. It is a poor fit for a vendor URL deliberately serving different bytes on every request unless the vendor offers a fixed, approved release.
Start with an inventory of the exact external URLs used by the purchase, account and support journeys. For each URL, record the owner, purpose, release version, whether it is script or CSS, which page loads it, and what happens when it fails. A payment widget used to complete an order needs a different fallback from a decorative animation. The question for the owner is whether the file is both important enough to protect and stable enough to approve byte for byte. SRI verifies delivered bytes against a chosen digest; it does not decide whether the approved code is safe or whether the supplier deserves access.
Approve and calculate the digest
Choose an immutable version URL or a release artifact controlled by the deployment process. Obtain the exact bytes the browser will fetch, review the intended version through the team's normal dependency process, and calculate a SHA-384 or SHA-512 base64 digest. Put the algorithm name and digest in the integrity attribute. MDN's SRI implementation guide describes this browser check and provides a command-line digest example. Do not paste a hash copied from an unrelated mirror merely because the filenames look alike: minification, line endings or a vendor rebuild can change the bytes. The chosen digest must describe the actual served asset.
For a cross-origin resource, include the crossorigin attribute and confirm that the asset server provides the necessary CORS response. MDN explains that an integrity-bearing cross-origin request cannot use the usual opaque no-cors mode; without the CORS arrangement the resource can fail even when its bytes are correct. Verify the response in a real browser, not only a local hash calculation. If the vendor cannot provide a stable version and CORS-compatible delivery, the team may choose a reviewed self-hosted copy where its licence and update process permit, or select a different integration. That is an operational decision, not a reason to publish an untested integrity attribute.
Plan for the rejected file
A mismatch is meant to fail closed: the browser does not run the unexpected script. For a nonessential page enhancement, that may be a small visual loss. For a checkout dependency, it may stop payment or hide a required form. Decide the customer-visible fallback before enabling the pin. The page can explain that checkout is temporarily unavailable, preserve the cart, and offer a safe retry or contact route. It must not silently mark an order as paid or encourage repeated payment attempts. Monitoring should distinguish a missing file, CORS failure and integrity mismatch, because the repairs differ.
Consider an illustrative release: a shop pins version A of a checkout helper, then the vendor replaces the bytes at the same URL with version B. The browser correctly blocks B while the old page still names A's digest. The release owner should inspect B, test it in a staging purchase, update the digest and URL together if approved, and deploy through normal change control. Disabling the check simply to make the red browser error disappear defeats the purpose. If a critical journey is already broken, use the prepared rollback or alternative payment route while investigating; do not invent a fresh hash for unreviewed content under pressure.
Understand the boundary of the control
SRI checks the external file identified by the element; it is not a general approval system for every subsequent network call that script makes. A script that matches its digest may still contain a defect or send data to places the business did not intend. An attacker who can edit both the HTML page and its integrity value can replace the pair. Continue to review the supplier, limit what the page exposes, use an appropriate Content Security Policy where practical, and maintain a dependency update path. The integrity value is one layer of a supply-chain decision, not a substitute for it.
CSS deserves the same inventory discipline when it comes from another origin. Unexpected stylesheet changes can obscure a warning, alter a form's layout or make a required choice difficult to see, even though CSS does not execute like JavaScript. Pin a stable stylesheet when the team can operate the update cycle, and verify that its own dependent assets still load as expected. Do not assume the integrity attribute of the top-level stylesheet proves every image or font it references. Decide which resources are critical to the customer's understanding and test the complete rendered journey after each approved update.
Release without surprise breakage
Start in a staging environment that uses the same CDN response path as production. Confirm the expected script and style load, then deliberately serve changed bytes in a test to verify that the browser blocks them and the fallback appears. Check browsers used by the shop and inspect console and network details for CORS or digest failures. Next, release to a limited surface where feasible and watch checkout completion errors, asset load errors and customer reports. If considering an Integrity-Policy header, MDN describes a report-only form as an initial way to observe missing integrity metadata before blocking; test support and reporting rather than assuming every browser behaves identically.
Write down who can approve a new digest. A normal library update changes the file and therefore requires a new value; the change record should link the reviewed release, the actual asset URL, the computed digest and the journey tests. Include a rollback plan that restores a known-good asset plus matching page markup, rather than rolling back only one half. If the vendor changes an unversioned URL without notice, the mismatch is useful evidence that the delivery contract is unsuitable. Negotiate a versioned file or move to an integration that the shop can verify and maintain deliberately.
Check a real customer journey
A useful acceptance case begins with an approved version loading normally from the production-like origin. Continue from product page to cart and checkout; verify every required control and any external widget. Repeat with a mismatched file and confirm that the page does not proceed as if payment succeeded. Repeat with missing CORS permission to ensure the error is diagnosable. Finally, roll the dependency forward to a reviewed release and back to the previous known-good pair. These tests prove that integrity checking and recovery are operational together, not merely that a hash string exists in HTML.
For the owner, the release decision has three questions. Can the supplier provide a stable, reviewable asset? Can the team maintain the digest whenever it intentionally updates that asset? Can a customer still understand what happened if the browser rejects it? If any answer is no, fix the delivery arrangement or fallback before pinning a critical dependency. If all are yes, document the exact file and test the failure route. The value of SRI is the ability to reject an unapproved change while keeping the business able to ship approved changes on purpose.
Keep a dependency owner and an exit route
Assign one owner to each pinned external file, with a named backup who can respond when the supplier publishes a security update. The owner should know where the file is loaded, how its digest is produced, what release proves the bytes, and which customer journey breaks if it is blocked. Keep that record near the deployment configuration so an emergency fix does not rely on someone remembering an old chat message. When the vendor retires a version, do not leave a pinned but unsupported library running indefinitely; schedule a reviewed replacement and retest the affected journey.
An exit route matters when a vendor changes its delivery model. If fixed bytes or compatible cross-origin headers disappear, decide whether a licensed local copy, a different provider, or removal of the feature is feasible. Evaluate the business cost of each: a local copy requires update ownership; a replacement needs integration and accessibility checks; removing a feature may change the customer promise. Write this decision before the next outage. SRI makes an unplanned change visible by blocking it, but the team still needs a planned way to continue serving customers with approved functionality. across each critical customer journey.
Before you proceed
- Is the external URL versioned and byte-stable?
- Does cross-origin delivery pass CORS and integrity checks?
- Is there a customer-safe failure and rollback route?
