The supplier that stopped existing, and the script that did not

· · Security Infrastructure

Open your website's page source and read the script tags. Not the ones your developer added last month: the ones nobody has touched in years. A slider library. A font loader. A tracking pixel from an agency you stopped using. Somewhere in that list you will probably find a company name you have to search for, because you cannot remember what it did.

Now ask a question almost nobody asks about a supplier: is that company still going?

The script tag does not care. It is an address written into your page, and your visitors' browsers dial it on every page load. If the business behind that address wound up three years ago, the tag stays where it is. Nothing warns you. Nothing turns red. From your site's point of view, the supplier's disappearance is a non-event.

It stops being a non-event when somebody else answers to their name.

Why abandonment is the awkward case

We have written before about the third-party code on your website you did not write, and about a supplier whose data feed was poisoned without a single file changing. Both assume a supplier who exists: someone who can be emailed, who publishes an incident notice, who answers for what happened.

Abandonment removes that. A content delivery network, or CDN, is a company that hosts files such as scripts and images on servers around the world so pages load faster. When one shuts down, its domain eventually stops being renewed and goes on sale like any other. The company is gone. The addresses it handed out are still sitting in thousands of other people's HTML.

Take netdna-ssl.com, the asset domain behind the old MaxCDN service. Public registration records show it was created afresh on 24 July 2025, long after the brand was retired, meaning the original owner let it lapse and a stranger picked it up. Reporting on the takeover describes wildcard DNS across the domain, so every hostname beneath it, including the ones still hard-coded in other people's pages, pointed at infrastructure the new owner controlled. As of today it does not resolve, so nothing is being served. That is a reprieve, not a fix. The registration runs to 2028 and the sites pointing at it have not changed.

For what happens when such a domain does resolve, see polyfill.io, a small compatibility script loaded by well over 100,000 sites. In 2024 it changed hands and the new owner served malicious redirects to some mobile visitors. None of those sites were breached. Each had approved a script tag years earlier and never revisited it.

Your scanners are looking in the wrong place

Dependency scanning and software composition analysis read what you build and ship: your package files, your repository, your container. A third-party script tag is none of those. The code never touches your server. It arrives in the visitor's browser, from someone else's machine, long after your last deploy passed every check you have.

It also varies by country, device, or whether the visitor is logged in, so a crawler can be shown something clean while a customer on a mobile network is shown something else. Meanwhile the script runs with the same privileges as your own code: it can read the page, read what is typed into a form as it is typed, and send it anywhere.

For anyone taking card payments this is no longer just good practice. PCI DSS version 4.0.1 requirements 6.4.3 and 11.6.1 became mandatory on 31 March 2025. Between them they require a written inventory of every script on a payment page with a business justification for each, assurance that each script is what you think it is, and a mechanism that alerts on unauthorised changes to payment page content. An assessor can ask to see the inventory and the alerts. "We have always loaded that one" is not an answer.

What to check

  • List every third-party script your site loads. Open the site, press F12, and read the Network tab, or use a free external checker. Write down every domain that is not yours.
  • For each one, confirm the company still exists and still owns that domain. This is the check nobody does. Search the company name. Look up the domain's registration date: if it was created recently but you added the tag years ago, it has changed hands. Treat that as urgent.
  • Delete anything nobody can justify. Free, immediate, and the biggest win. A tag for a campaign that ended is a permanent invitation with no upside.
  • Add subresource integrity where you can. Subresource integrity, or SRI, is an attribute on the script tag holding a cryptographic fingerprint of the exact file you approved, so a file altered by even one character will not run. It suits fixed libraries well and scripts built to change often, such as most analytics tags, poorly.
  • Set a content security policy. A content security policy is an HTTP header listing which domains may run code on your pages, blocking anything else. Start in report-only mode, which blocks nothing and only reports what it would have blocked, so the first deployment cannot break the site and hands you an accurate inventory.
  • Keep third-party code off your payment and login pages. Marketing tags do not belong where people type card details.

The shift in thinking is small but it changes what you look for. A supplier relationship does not end when you stop hearing from the supplier. It ends when you remove their address from your page.

How Steelwise can help

Working out what your site actually loads, who owns each of those domains today, and what should be stripped off your sensitive pages is a short piece of work with a clear answer at the end. Get in touch if you would like a second opinion on yours.

Further reading

← All filings

We use cookies to understand how visitors use this site. More information.