Third-Party Script Risks: Hijacked CDNs and Brand-New Domains
Every <script src> that points at another domain runs with the same power as your own code. If
that domain changes hands or is broken into, every site that loads it starts serving the new
owner’s code the next time a visitor arrives, with no change on your side.
That is what happened to polyfill.io in 2024. The popular service changed owners, and the new operator served malware and redirects to visitors of more than 100,000 sites that still had the script tag. Many of them only found out when Google started warning their advertisers.
What we check
- Known compromised hosts. Script, frame and stylesheet hosts that are publicly documented as having served malware (polyfill.io and the domains of the same operation). A match from the incident’s malicious domains counts as confirmed; related domains of the same operator count as a strong sign.
- Brand-new domains. Third-party scripts and frames from domains registered in the last 30 days, looked up in the domain registries (only the domain name is sent). Attack infrastructure is usually days old. Large, long-established hosts are skipped.
| Check | Result when found |
|---|---|
| Known compromised host | Fail (confirmed or strong sign) |
| Brand-new domain | Warning (weak sign); a fail when other signs point at the same domain |
A new domain on its own is often innocent: a new chat widget, a new analytics vendor. It becomes a strong sign when the same domain also appears in a packed script or a hidden frame.
How to keep third-party code under control
- Know every script. Keep a list of third-party scripts, who added them and why. Remove what nobody can explain, including old tags in a tag manager.
- Self-host stable libraries. Copy libraries such as polyfills, jQuery or fonts to your own server instead of loading them from a CDN you don’t control.
- Pin what you load from CDNs. Use exact versions and add Subresource Integrity (
integrityattributes), so a changed file is refused by the browser instead of executed. - Restrict with CSP. A Content Security Policy that lists allowed script hosts stops a script from a new domain from running at all.
- Watch for changes. A monitor on your account re-scans the page and emails you when it starts loading code from a host it didn’t load before.