rjaWebsThe hidden risk in "just add this script"
Modern sites lean heavily on code hosted by other people: a font script here, an analytics snippet there, a widget pulled from a content delivery network. It's convenient and usually harmless. But it means part of your website is being served from a machine you don't control — and if that machine is ever compromised, or the company behind it changes hands, your visitors can be handed something you never approved, without a single line of your own code changing.
A real example, not a hypothetical
In mid-2024 this happened at scale. A widely used helper script called Polyfill.io — embedded on well over a hundred thousand websites — changed ownership, and the domain began quietly serving malicious code to unsuspecting visitors. The site owners hadn't touched anything; the code they had trusted for years simply turned on them. It echoed the earlier "Magecart" attacks, in which card-skimming scripts were slipped onto the checkout pages of major brands and harvested payment details for months. In each case the weak point wasn't the site's own code — it was borrowed code that changed underneath it.
How Subresource Integrity closes the gap
Subresource Integrity (SRI) is a browser feature that works like a fingerprint. When a site includes an outside file, it records a cryptographic hash of the exact version that was reviewed and approved. The browser then checks every future load against that fingerprint, and if the file has changed — for any reason at all — it refuses to run it. The trade-off is that it suits files which aren't supposed to change on their own; a script designed to update itself will, by design, break its own fingerprint, so knowing which is which is part of the job. Our own first instinct is to pull in as little outside code as possible in the first place, and to pin and fingerprint whatever genuinely has to be there.