Just the Facts · Article

Code you didn't write, running on your site tonight

Every third-party script tag is a standing invitation for whoever owns that domain to run code on your visitors — forever, without telling you. Including the fix that most people recommend for it, and why it wouldn't have worked.

You vetted that script once, probably years ago. The domain it loads from can be sold tomorrow, and the new owner can change what it does tonight. You would not be notified, and nothing on your site would look different.

This is not hypothetical

In February 2024 the domain behind polyfill.io — a widely embedded JavaScript library — was sold to a new owner. In June, the domain began serving tampered code that injected a fake Google Analytics script from a lookalike domain and redirected visitors to gambling and adult sites.

The code was carefully built to avoid discovery. It only activated on certain mobile devices, at certain hours, suppressed itself when it detected an administrator or a web analytics tool, and delayed execution to slip past scanners. Site owners had no reason to suspect anything.

On scale, be careful with the numbers you'll see quoted. The original researchers estimated over 100,000 affected websites. A separate scan a week later counted 384,773 hosts still referencing the domain — but that counts hosts, not businesses, and around two-thirds of them sat inside a single German hosting provider, which points at parked and boilerplate pages rather than live companies. The honest statement is: over a hundred thousand sites, including some very large names.

The uncomfortable part: the usual fix wouldn't have helped

Subresource Integrity is what almost everyone recommends after an incident like this, and it is what this report checks for. It works by pinning a cryptographic fingerprint of the exact file in your page. If the file changes by a single byte, the browser refuses to run it.

It could not have protected anyone here. The whole purpose of polyfill.io was to serve different code to different browsers — it read the browser's identity and returned only the pieces that browser was missing. One address, different bytes every time, so no fixed fingerprint was possible. The project's own maintainers had established this years before the attack. Worse, the attacker's payload was itself generated dynamically, hiding inside exactly the variability that made fingerprinting impossible.

We would rather tell you this than sell you a fix that wouldn't have worked. Integrity checking is genuinely valuable — but only for files that don't change: a pinned, versioned library from a CDN. For anything that generates its response per visitor, it is not available to you, and claiming otherwise is how people end up feeling protected while they aren't.

What would actually have stopped it

Not loading it. The library's original author had already said publicly, months before the attack, that no modern website needs those polyfills. Zero third-party code is the only complete control.
Hosting the file yourself. The risk was that someone else could change the bytes. Serving your own copy removes that ability entirely — and once you do, integrity checking becomes redundant.
A Content-Security-Policy script allowlist. This is the control that survives where fingerprinting can't: a policy that only permits scripts from approved sources would have blocked the injected lookalike script even though the parent file was dynamic. Its limit, stated honestly: it would not have stopped a payload that redirected the browser directly rather than injecting a script tag.
Watching your dependencies. The February sale was public. Cloudflare acted on it four months before anything malicious happened. Somebody was paying attention; most site owners weren't.

The version of this that reaches payment pages

In 2018 a chatbot supplied by a third-party vendor and embedded on Ticketmaster's payment pages was compromised. The vendor's JavaScript captured everything customers typed into those pages, including card details. Ticketmaster notified 9.4 million people in Europe; card details of 66,000 were taken. The UK regulator fined Ticketmaster £1.25 million.

That is the cleanest illustration of the exposure: the compromised code was not Ticketmaster's, was not on Ticketmaster's servers, and had been added for an ordinary business reason. The liability landed on Ticketmaster anyway.

What to actually do

Inventory every third-party script on your site and write down why each one is there. Most sites carry at least one nobody can justify.
Delete the ones that fail that test. It is the highest-value security change available to a small site and it costs nothing.
Self-host what you can. Fonts, small libraries and analytics helpers rarely need to come from someone else's domain.
Add integrity checking where the file is genuinely static and versioned — it's cheap and it works there.
Keep third-party scripts off pages that collect payment or sensitive personal information, wherever that's possible at all.

Technical guidance, not legal advice. Integrity checking protects against modification of static files only; it is not a general defence against third-party compromise.

Sources

Questions? Contact us