Subresource Integrity for Third-Party Scripts

Service sites often load fonts, analytics, booking widgets, or UI libraries from a content delivery network (CDN) they do not operate. That choice reduces hosting work and can improve cache reuse. It also widens the supply chain: if the remote file changes—through compromise, a mistaken publish, or an unexpected “latest” URL—visitors execute whatever arrives.

Subresource Integrity (SRI) is the browser feature built for that gap. MDN describes it as a way to verify that fetched resources match a cryptographic hash you supply. The W3C Subresource Integrity specification states the same goal in stronger terms: authors should be able to pin content, not only authenticate the server with TLS.

---

Why HTTPS alone does not pin the file

TLS, HSTS, and related mechanisms authenticate the server, not a specific byte sequence. The W3C SRI introduction is clear: an attacker—or an administrator—with access to the CDN host can change the delivered file while the connection remains “secure.” DNS tricks and hostile mirrors raise a related risk: the browser may talk to a host that is not the one you intended, still over HTTPS.

MDN frames the everyday case as a supply-chain attack. A page on https://example.com includes https://not-example.com/script.js. If that third-party host is altered, every site that trusted the URL inherits the change. SRI does not remove the need for HTTPS; it adds a second check: after the bytes arrive, the browser hashes them and compares the digest to the integrity value in your markup. On mismatch, the resource must not execute or apply—MDN and the W3C both describe this as refusing the load (a network error), rather than silently running untrusted content.

A short analogy: HTTPS confirms you reached the warehouse you dialed. SRI confirms the crate’s contents still match the packing list you signed.

---

How the integrity attribute works

You attach SRI to <script> elements and to <link> elements whose rel is stylesheet, preload, or modulepreload (MDN). The integrity value is one or more digests, each prefixed with the algorithm token:

Piece	Role
Algorithm	sha256, sha384, or sha512 (W3C valid SRI hash algorithm tokens; SHA-384 is a common baseline in the spec’s security notes)
Digest	Base64-encoded hash of the exact resource bytes you expect
crossorigin	Required for cross-origin SRI so the request uses CORS; typically anonymous for public CDN files

Example shape (illustrative hash only—generate a real digest for your file):

<script
  src="https://cdn.example.com/library.min.js"
  integrity="sha384-Li9vy3DqF8tnTXuiaAJuML3ky+er10rcgNR/VqsVpcw+ThHmYcwiB1pbOxEbzJr7"
  crossorigin="anonymous"></script>

The W3C document explains browser selection when multiple hashes are present: the user agent prefers the strongest supported algorithm in the list, then accepts the resource if any digest for that algorithm matches. Authors can list more than one hash to allow controlled alternates or to migrate algorithms without stranding older browsers.

Cross-origin detail matters operationally. MDN notes that HTML-loaded resources default to no-cors mode, which can succeed without exposing response bytes to the page. SRI needs those bytes to verify the hash, so browsers require CORS for integrity-protected cross-origin loads. Omitting crossorigin is a common reason a first SRI rollout “breaks” a working script: the check cannot complete safely, so the load fails closed.

MDN documents OpenSSL and related command-line flows for generating digests (for example, hashing a file with SHA-384 and Base64-encoding the binary digest). Many CDNs also publish ready-made snippets that already include integrity and crossorigin for a pinned version URL.

---

What adoption data shows—and where SRI fits on a service site

The HTTP Archive’s Web Almanac 2025 security chapter (published January 15, 2026; last updated January 16, 2026; authors Vik Vanderlinden and Gertjan Franken) reports SRI on 25.9% of desktop pages and 23.6% of mobile pages—about a 2.5 percentage-point rise versus the prior year. Coverage within a page is thinner: at the median, only about 2.82% of a page’s scripts carry SRI; even at the 90th percentile, coverage reaches only about 12.5% of scripts.

That pattern matches how service sites should prioritize. Almanac analysis finds SRI-protected scripts concentrated on CDN hosts—the resources developers do not fully control. Pinning a versioned jQuery, Bootstrap, or similar library from a CDN is a high-value, low-drama use case. Tag managers and analytics endpoints that rewrite payloads frequently are a poor first target: a correct SRI hash for yesterday’s bytes will block today’s legitimate update.

Practical targeting for a typical service business site:

• Good SRI candidates: version-pinned CDN libraries, static widgets you have reviewed, first-party assets mirrored to a CDN when the hash is part of your release.
• Weak SRI candidates: “latest” URLs, A/B or personalization scripts that change bytes often, and third-party loaders that inject further scripts you never hash (SRI on the first tag does not automatically protect those children).

MDN also documents newer Integrity-Policy / Integrity-Policy-Report-Only headers that can require integrity metadata on script or style destinations. Report-only mode is the safer rollout step: collect violations before blocking.

---

Limits and tradeoffs

SRI verifies exact bytes. It does not prove the original author was trustworthy, nor does it review what a correctly hashed script does. A malicious-but-stable file passes. Proxies that transform responses must keep digests in sync; the W3C notes Cache-Control: no-transform as a signal, and optimizing intermediaries that alter content without updating hashes will cause failures.

Failed checks surface as load errors. That is the point—and the operational cost. Teams need a process to recompute hashes when bumping versions, ideally in the build or release checklist. Integrity metadata delivered over plain HTTP can itself be altered in transit; both MDN’s ecosystem and the W3C security considerations assume HTTPS for serious use.

Finally, Almanac’s page-level adoption figures do not mean most third-party script weight is protected. Selective pinning of the few stable CDN includes on a service homepage is still a meaningful hardening step.

---

Practical takeaways for your next website

1. Inventory remote scripts and styles. List every cross-origin <script> and stylesheet; mark which URLs are version-pinned and byte-stable.
2. Hash the stable ones. Generate sha384 (or sha512) digests for those files; add integrity plus crossorigin="anonymous".
3. Prefer versioned URLs. Pin [email protected] (or a content-hashed filename), not /library.min.js that silently updates.
4. Automate hash updates. Tie digest regeneration to dependency bumps so a CDN upgrade cannot ship with a stale hash—or worse, no hash.
5. Know what SRI does not cover. Child scripts injected by a third party, frequently changing tags, and first-party XSS are outside this control; pair SRI with careful script selection and, where appropriate, Content Security Policy.

---

Ready to Discuss Your Website?

If you are planning a new website, a service redesign, or custom development for your business, we’re here to help shape the work—including third-party script choices and integrity checks that keep CDN convenience from becoming an unchecked trust relationship.

• Explore Our Services: Web Design · Web Development · Website Redesign
• Start a Conversation: Tell us about your project via our Contact Form or email us directly at [email protected].