New: Free Speed Report. No code, no commitment. Just performance insights, built for your site. Get your report

Your Code Freeze Doesn’t Cover the Code You Don’t Host

On October 29, traders on Polymarket started seeing positions sold and funds moved that they hadn’t touched. The cause was a script the site loaded from an outside performance-monitoring vendor. That script had been replaced with code that used signed-in traders’ own sessions to drain their wallets. Polymarket says 726 wallets were affected and it is returning $3.9 million in total, including about $2.7 million taken directly (SecurityWeek).

The vendor, DebugBear, says its DNS records were compromised through its domain registrar, that early findings point to one targeted customer, and that it has found no sign its own systems were breached (SecurityWeek). Each customer loads its own copy of the script, and the file that was swapped was Polymarket’s (The Hacker News).

Sure, Polymarket is a prediction market, not a retailer. But the mechanism is still one every digital storefront runs on. Your page asks another company’s server for code, and the browser runs whatever comes back.

A code freeze stops at your own deploys

Black Friday is November 27. Most eCommerce teams are entering code freeze now, and the logic is sound: fewer changes, fewer surprises during the most expensive week of the year.

But a freeze only covers what you ship. A tag that loads from a vendor’s domain can change on any day without a release on your side. Usually that’s a performance problem: a vendor pushes a heavier build, adds a request or slows down under load, and your pages get slower during peak. Yottaa’s data shows third-party apps already account for 44% of eCommerce load time. That’s a large share of the page your team doesn’t directly control.

October 29 showed the same blind spot can be a security problem. The file that changed belonged to a performance tool, the kind of script teams add for visibility and rarely think about again.

Treat third-party code as inventory

Polymarket says it is putting third-party scripts back with extra checks, including a stronger Content Security Policy, pinned versions and sandboxing (The Hacker News). eCommerce teams don’t need to wait for an incident to do the same thinking. Three questions are worth answering before the freeze.

What runs on checkout and sign-in pages, and does it need to? Researchers at Hudson Rock advised keeping unneeded third-party code off pages where users trade or sign (The Hacker News). For a store, those are checkout, account and payment pages. Every tag that runs there should have a named owner and a reason. Check for tags that load site-wide only because nobody scoped them. Fewer scripts on checkout is also a faster checkout.

Which tags can you pin? Subresource Integrity lets the browser refuse a file whose contents don’t match a hash you set (MDN). A swapped file then fails to load instead of running. The catch is that many vendor tags change by design, so you can pin only the files with fixed versions, and the vendor’s server has to support cross-origin requests. An allowlist alone doesn’t do this job. Allowing a trusted domain in your security policy doesn’t check the files that domain serves (The Hacker News).

Who can turn a tag off, and how fast? Polymarket removed the script “within the hour” (SecurityWeek). During a freeze, the fastest response is one that doesn’t need a deploy. Know who owns each vendor relationship, and make sure you can block a tag at the edge or in your tag-management layer without a storefront release. In Yottaa, Application Sequencing includes a block rule for this, so a tag can be switched off whether it loads from a tag manager or from site source.

This applies to every vendor on the page, performance vendors included. Yottaa runs a script on its customers’ pages too, and buyers are right to ask us these questions.

What changes after peak

Expect harder questions in security reviews for any tag that touches a page with a signed-in user. That’s healthy. For years, third-party scripts have been judged one at a time, on what each vendor says it adds. This incident makes the cost side harder to ignore: every tag adds load time, and every tag adds something you are trusting to stay the same.

The teams that come through peak in good shape will be the ones that already know what loads on their most valuable pages, in what order and on whose authority.

If a vendor’s file changed on your checkout tonight, how long would it take your team to notice?