External scripts need an owner inside your business

Every external script on a business website delegates some control over the visitor's page to another operator. That delegation can outlive the person who added the script and the company that originally supplied it. The practical response is to keep reviewed, stable dependencies under your own release process where feasible, pin external files where possible, and give every remaining exception a named owner.

The polyfill.io incident made the ownership problem concrete. It was not enough to remember that a service had once been reputable. A website kept requesting code from the same address while the organization controlling that address changed.

Ownership changed before the public warning

Sansec's report, published on 25 June 2024, described malicious code delivered through polyfill.io after its ownership changed. Its analysis showed conditional redirects, including checks that could make a casual desktop visit miss the behaviour. The report contains later updates; its publication date should not be confused with the date malicious activity first occurred.

Cloudflare's response is dated 26 June, one day after the historical assignment week ended. It is later supporting evidence. Cloudflare described the February sale to Funnull and reported corroborating observations from its own systems. This supports an ownership-risk argument without requiring a claim that the original operator's credentials were stolen.

Looking back from November 2026, these are historical incident reports, not a statement about what every named domain serves today. Nor does a headline estimate of affected websites establish how many visitors suffered harm. The argument needs neither an exact victim count nor a claim that every visitor received the same payload.

A script inherits the page's trust

An ordinary external script executes in the embedding page's environment. Depending on that page and its protections, it can read displayed information, alter forms or load further code. This is a risk of the permission being granted, not a claim that the polyfill incident performed every one of those actions. MDN's Subresource Integrity explanation describes the underlying threat of a third-party host replacing a loaded file.

HTTPS protects the connection to the selected server. It does not prove that today's operator will deliver the same behaviour as yesterday's. A familiar domain in a template can therefore remain an active supply-chain dependency long after everyone has stopped thinking of it as a choice.

For an illustrative appointment site, a formatting helper and a booking widget may both arrive through script tags, yet the business consequences differ. The helper might be removable; the widget might be essential to bookings. Both need an owner, but the fallback and removal plan should reflect their actual role.

Pin bytes as well as names

Subresource Integrity, or SRI, lets the page specify an expected hash for a loaded resource. The browser rejects a file that fails the check. Cross-origin use also requires appropriate CORS support. These mechanics are described in MDN's SRI documentation, including the need for the integrity metadata.

SRI can check a URL called latest; it simply stops loading the script when the returned bytes change. That makes a mutable URL operationally awkward, rather than exempt from integrity checks. A versioned, stable resource makes a deliberate update and new hash easier to manage. Polyfill services that vary output by browser or request options need particular care because one expected hash may not match every response.

A hash also approves bytes, not their quality. If the team obtains its file and hash from an already compromised source, the browser faithfully checks the wrong baseline. Review the dependency before accepting it, and treat updates as releases. SRI on an initial loader does not automatically validate everything that loader subsequently retrieves.

Restrict loading without confusing it with approval

A Content Security Policy can restrict script sources and other resource loading. MDN's CSP guide explains these controls and deployment considerations. A policy that allows an external host still allows permitted code from that host; it does not distinguish its helpful revision from a malicious replacement.

Use CSP alongside integrity checks and a smaller dependency set. Introduce policy changes with attention to reports and the actual booking or checkout journey. An unexpectedly blocked essential script can interrupt business just as surely as a failed deployment. No CSP configuration or exploit was executed for this article; the recommendations require validation on the site concerned.

Self-hosting can move a stable library into the business's reviewed release process. It also transfers update responsibility. Serving a vulnerable old copy forever is not a successful outcome. Dynamic services that require vendor infrastructure may not have a practical self-hosted replacement.

Start an audit small enough to finish

Set aside an initial hour to list direct external scripts on the important pages. Treat that as a first pass, not a complete security audit. Include tag managers and note that they can introduce additional dependencies. Inspect what the page actually loads as well as what appears in the repository.

For each entry, record its business purpose, controlling organization, update mechanism and internal owner. Decide whether it can be removed, served locally or pinned. For an indispensable service that changes dynamically, record why it remains and how the business will respond if it must be disabled.

There is a legitimate argument for vendor-operated scripts: some useful services cannot be delivered as a static local file, and a small business cannot build every integration itself. Keep those exceptions where their value justifies the dependency. Make them visible in software maintenance so a change of supplier, ownership or behaviour triggers a decision. The avoidable failure is a live grant of page authority that nobody inside the business remembers owning.