How much of your store do you actually control?

2026-10-26

Third-party apps, client-facing code, and the case for owning the small things

• Ecommerce
• Cybersecurity
• Ecommerce Strategy
• Shopify

Third-party apps, client-facing code, and the case for owning the small things

​

Two weeks of other people's incidents

On 10 October, a developer in Germany, Roman Zipp, was buying a keyboard from a US retailer that runs on Shopify. He pressed Checkout and landed on what looked like a Shopify checkout. When he clicked into the first-name field, his password manager offered to fill in the name on his credit card, which made him look at the address bar. The page sat on a domain called biliing[.]top. He traced the redirect back to Hulk Product Options, a popular app for adding custom fields to products. The malicious script had been saved as custom JavaScript in the app's settings, held on the developer's own servers, and it loaded on every page view of every store using that configuration.

Over the following ten days, the same thing surfaced elsewhere. Logbase, which makes the Selleasy upsell app, confirmed that someone got into one of its internal tools on 13 October and added a malicious script to the Selleasy settings of a number of stores; the attack ran from 07:47 to 15:00 UTC. Swym confirmed a similar incident through its Wishlist Plus app and went on to pause the app for every merchant. Shopify disabled Boost AI Search & Filter on 17 October over a security issue. Merchants have named several other apps, but those reports haven't been confirmed by the developers, and of the roughly 480 apps that left the Shopify App Store in the second half of October, most have no stated link to the attack. Apps are delisted for routine reasons all the time, and an API deadline happened to fall on 16 October.

WordPress had a similar fortnight. Some downloads of the paid Rank Math PRO SEO plugin between 15 and 16 October carried malware. A couple of days later, an attacker holding stolen UpdraftCentral keys, the remote management channel that ships with the UpdraftPlus backup plugin, used them to push backdoor plugins onto connected sites; Patchstack counted 99 different disguises between 18 and 19 October. Back in June, the OptinMonster and TrustPulse pop-up plugins served malicious scripts to site visitors after their vendor's content delivery network was compromised.

Different platforms, different attackers, all of them with the same 'shape': code that the store owner didn't write, code that's controlled from servers the store owner can't see, code that's running in front of the store owner's customers. That's what this article is about. The hacks are just the most dramatic example of it.

A store built out of other people's businesses

Most Shopify stores I have worked with or audited run more apps than anyone in the business can list from memory. Each of those apps is a small company's product, and a lot of them are built by a handful of people or a single developer. Reach and size are different things here. Logbase told iTnews that more than 49,000 active stores use Selleasy, which means one vendor's internal tooling sat inside tens of thousands of other businesses.

Every one of those vendors has their own release cycle, their own staffing, their own funding and their own pricing decisions and each one of them can change what your customers see. Attacks are the exception. The norm is something much quieter: a plan changes, a usage cap is hit, a developer is acquired, a product is wound down. A 2025 merchant review of Swym Wishlist Plus on the App Store notes that the wishlist simply disappeared from the store mid-month as the plan's action limit was reached, at the very point that customers were starting to use it. No attack took place on that store. A commercial rule in someone else's billing system simply switched off a feature on their product pages.

The maths is brutal. Let's say each app has a 99% chance of making it through a month without anything that users can see breaking. With 20 apps, that probability is around 82%. With 40 apps, it's down to around 67% (so roughly a one-in-three chance of something user-facing going wrong in any given month). That 99% is my own example, not an actual figure. Real apps aren't independent either. Whatever number you pick, the trend is the same, and each additional app makes it less likely that you'll have a clean month.

Black Friday, 11am

Black Friday falls on 27 November this year. Picture the busiest hour of your trading year and three apps failing inside it.

The product options app stops loading. On a store selling engraved, monogrammed or made-to-measure products, the option fields vanish, and either the Add to bag button does nothing or orders arrive without the personalisation the customer paid for. Then the search and filter app goes down. If it replaced the theme's own collection template, there may be nothing to fall back on, and shoppers land on a category of 600 products with no way to narrow it. Finally, the consent banner fails to load. Depending on how it is wired, your analytics and ad pixels either stop firing, so you buy the most expensive traffic of the year blind, or they fire without consent, which turns a marketing problem into a legal one.

Customers don't experience any of this as an app failure. Attribution theory, which goes back to Bernard Weiner's work in the 1980s, describes how people explain a failure by pinning it on a cause, and the cause they reach for is the one in front of them. In a browser, that is the brand in the address bar. The customer who can't add a monogram doesn't think about HulkApps. They conclude that your site is broken, and on Black Friday the next site is one tab away, very likely running the same offer.

The commercial damage lands exactly where you have spent most. Peak traffic is the dearest of the year, whether it comes from paid search, affiliate commission or an email list you have been warming up since September. A broken feature in that window lowers conversion on traffic that is already paid for, and every hour of it pulls revenue per visitor down on the one day it should be at its highest.

Who holds the keys

Every app that touches your storefront holds a key to it. Some sit in the theme as app embeds or theme app extensions. Some load scripts from their own servers. Many come with a settings screen in the vendor's own dashboard, often with a box for custom code, and nothing typed there ever passes through your developers, your version control or your release process. The Hulk, Selleasy and Swym incidents all went through that route. The merchants' themes were clean, so a code review would have found nothing, because the script arrived as app settings at the moment the page loaded.

That widens the circle of people who can change your shop. On paper, only your team ships changes to what customers see. In practice, anyone with access to any of those dashboards can do it: the vendor's staff, their contractors, whoever steals one of their passwords, and whoever breaks into a tool they built for internal use. Logbase's own account of its incident describes exactly that: an internal tool used by someone who shouldn't have had it. Nobody would hand forty people the keys to a physical shop without knowing who they were. Online, plenty of retailers have done it without ever counting.

Keys also live on past their prime. In the UpdraftCentral case, Patchstack reported that connecting a site to a TeamUpdraft account would enable remote management by default, and Nethemba found keys issued in November 2025 were still being accepted in October 2026. On Shopify, an app installed for a single campaign will retain its permissions until it is removed, and older apps could leave behind snippets in a theme after they'd been uninstalled. The fewer keys you issue, the shorter the list you have to maintain.

Even the platform holds one. On 20 October, Shopify made every online store ask customers to confirm before sending them to another website. Three days later it narrowed that to sites it considers suspicious or malicious. Both were sensible responses to the attacks, and neither was any merchant's decision.

The 3am problem

If something you've built breaks, then your team fix it on your timetable. If something a vendor has built breaks, then the clock is theirs. WAGD found out just how long that clock can be. The store was hit via Selleasy on 13th October, and Carly Clarke (the owner) only found out about it because a customer who worked in tech happened to send her screenshots of the fake checkout. She shut the store immediately. Shopify support asked her to keep the password page up whilst they investigated and gave her no date at all. On the 19th October, iTnews reported that she'd been told she could reopen. That's about six days with the store closed, most of it after the developer had already taken the code out.

Clarke told iTnews she had received "more information from individual app developers than from Shopify itself". That is the second half of the problem. During an incident, you depend on parties who don't report to you, who are dealing with thousands of other merchants at the same moment, and who decide for themselves what to tell you and when.

Time zones make it worse. Selleasy's attack window of 07:47 to 15:00 UTC ran from 6:47pm to 2am in eastern Australia. When the vendor sits in one hemisphere and the merchant in another, an incident can start while one side is asleep and be half over before the other side wakes up. Small app vendors, in my experience, rarely offer an SLA you could enforce, so the speed of the fix comes down to goodwill and whoever happens to be on shift.

Last week I wrote about what an outage does to shopping habits: every day a customer can't buy from you is a day spent practising buying somewhere else. When the outage comes from someone else's code, you carry exactly the same cost with even less say over when it ends.

What I own, and what I still buy

None of this is to say you have to build everything yourself, and in certain areas that's simply not viable. Payments, fraud screening, tax calculation, your email and CRM platform and on large catalogues, the search engine itself are all areas where it's far more sensible to buy from a specialist with the security team, the contracts and the scale to back it up. No sensible person is going to write their own payment gateway, and on Shopify the checkout is the platform's own anyway.

The test I use has two questions: does the customer see it, and how complex is it really? The small, simple, client-facing pieces are where apps add the most risk for the least value. Product options, a size guide, an estimated delivery date, a wishlist, product badges, a free-delivery progress bar, a cross-sell block on the product page: each of these is a modest piece of theme work, often a metafield and a section. The native tools have caught up, too. Variants and metafields cover most product options, Shopify's own Search & Discovery app handles standard filtering, and Shopify Functions take care of a lot of discount and bundling logic that used to need an app. Once that code is in your theme and in your repository, it only changes when your team ship a change. It loads nothing from a third-party server, and it's still working the week after the vendor has gone quiet

Where a complex client-facing feature is still a feature worth having, I want a fallback that I control. That means the native collection template has to remain in play underneath the filter app so it can be switched back on in minutes. I also want to go with the bigger, more accountable vendor rather than the cheaper niche one, having asked them very clearly what happens to my store when their service is down.

The commercial case goes well beyond security. Fewer third-party scripts means lighter pages, fewer monthly subscriptions and a significantly shorter list of things to test before the peak code freeze. The most compelling argument is also the simplest one. If something breaks on the busiest day of the year, I want the fix to be ours to make.