Some of your apps can edit your checkout.

The shopper who read the address bar

Roman Zipp, a developer in Germany, was looking at a keyboard on mechanicalkeyboards.com, a store that runs on Shopify. He only wanted to see what shipping would cost, so he put it in his cart and pressed Checkout.

The page that came up looked like a Shopify checkout. The logo was a little off, but he'd seen stores with mismatched logos before. What stopped him was his password manager. When he clicked the first-name field, it offered to fill in the name from his credit card instead of his own. So he looked at the address bar. He wasn't on the store's checkout at all. He was on a site called biliing(.)top, with an i where the second l in "billing" should be.

He wrote the whole thing up on his blog, and the post went up on Saturday. If you run a store it's worth reading in full, because it's careful about what he found and what he doesn't know. His timeline puts the discovery on October 1, and he emailed the store and the app's developer that day. On Saturday he reported the domains to the malware tracker URLhaus and to Google Safe Browsing, Shopify escalated it internally, and by his account the redirect on that store was gone about sixteen minutes later.

The part that should stay with you is the ending. Zipp let the fake page take some made-up details to see what it would do. It sent them off to its own server and then forwarded him to the real checkout. A shopper who didn't notice would have finished their order as normal, and the store would have seen an ordinary order. The only person in a position to spot anything was the customer, and only if they happened to look.

What actually ran

Here's what he traced, in plain terms.

The store had an app installed called Product Options by HulkApps, which adds extra choices to product pages. Like many Shopify apps, it puts a small script on the storefront, and that script is delivered from Shopify's own servers. Nothing about it looks unusual.

When a page loads, the script asks the app's server for the store's settings. Zipp found that the reply included a field for custom JavaScript, and in that field about 22.7 KB of code containing a function named, helpfully, "hijack." It waited for a shopper to press Checkout in the cart and sent them to the look-alike page instead. It only did this once per visit, leaving a marker in the browser so it wouldn't try twice. The settings also listed two more look-alike addresses, checkout-confirm(.)top and order-confirm(.)top.

Two more details matter. His ad blockers and DNS malware filtering didn't catch any of it, and none of the three domains was on URLhaus or Safe Browsing when he checked. And he found a Reddit post from the owner of a vape shop, about 18 days old when he saw it, describing the same domain and saying they'd contacted Shopify.

What nobody knows yet is how the code got into that settings field. Zipp lists the possibilities himself: the store owner's HulkApps account was taken over, a HulkApps employee's account was, HulkApps itself was compromised, or another app on the store changed the setting. He knows of two affected stores, and Shopify couldn't tell him how many others there were. We hadn't seen a statement from HulkApps or Shopify when we wrote this, so treat the cause as open. This isn't a verdict on one developer. It's a look at how a store's checkout can be changed from outside the store.

A settings box that runs on your checkout

Take the names away and the lesson is about a kind of setting, not a particular app.

Plenty of store apps have a box somewhere in their own dashboard called custom code, custom JavaScript, or advanced settings. It's there for good reasons. A developer needs to nudge a layout, fix a clash with your theme, or send an analytics event. Whatever goes in that box is sent to every visitor's browser and runs on your storefront as if it were part of your site.

So that box is part of your checkout, even though it lives in somebody else's dashboard. Whoever can sign in to that app can change what your customers see and where your Checkout button goes. Your Shopify staff accounts can be locked down perfectly, with two-step sign-in for everyone, and it won't help if the app keeps its own login that nobody has looked at since the agency set it up.

It also explains why the usual alarms stayed quiet. The script came from a normal place. The app was a real app doing its real job. The harmful part arrived as a setting, and it showed itself once per visit, only to shoppers who got as far as the cart.

We wrote recently about the logins to outside tools that can see and message your customers. This is the other half of that list: the tools that can change your storefront. Some apps will be on both.

Walk your own checkout

The cheapest check is the one Zipp suggests: go through your own checkout the way a stranger would.

Open a fresh private or incognito window. That matters here, because this script fired once per visit, and the tab you've had open all week, signed in to your admin, isn't what a customer sees. Go to the store, put something in the cart and press Checkout. When the payment page appears, read the address bar properly, letter by letter. It should be your store's own address, not somewhere you've never heard of. Then do the same on your phone, on mobile data rather than the office Wi-Fi, because that's how a lot of your customers arrive.

Make it a habit rather than a one-off. Once a week is reasonable for a small store, and always after you install an app, update one or change its settings. Put a name next to the job so it doesn't quietly stop happening. It takes three minutes.

Be honest about what it can't tell you. One clean walk-through doesn't prove you're clear, because code like this can be written to show itself only to some visitors. It's still the quickest way to catch the plain version, and the plain version is the one you'd least like to hear about from a customer first.

List the apps that can run code, and who can change it

Next, make a short list. In Shopify, start with the apps page in your admin, then open the theme editor and look at App embeds, which shows the app pieces switched on in your theme. If a developer or agency has worked on the store, ask what they've added to the theme code directly, and check Customer events in Settings for any custom pixels.

For each app on the list, ask four questions.

• Does it put anything on the storefront? Plenty of apps only work inside the admin. The ones that add scripts to your pages are the ones to look at.
• Does it have a custom code or advanced settings box, and is anything in it? If there is, find out who put it there and why. If nobody knows, that tells you something. If you don't use the feature, empty it and switch it off.
• Who can sign in to the app's own dashboard? Many apps keep accounts separate from your Shopify staff. Find out who has one, make two-step sign-in required, and remove people who've left, including former agencies and freelancers.
• Do we still use it? An app you tried for one sale two years ago still runs on every page if it's still installed. Uninstall it, then check App embeds and the theme in case it left something behind.

You'll probably end up with fewer apps, and the ones that stay will be ones somebody can explain. Write the list down with an owner for each app, and you have what you need for the next section before you need it.

When a customer says the checkout looked odd

Zipp emailed the store the day he found the redirect. By his timeline it was still there nine days later. We don't know what happened to that email, and it's easy to see how a message like it gets filed as a confused customer. So tell whoever answers your support inbox that "the checkout looked different," "the logo was wrong," "it asked for my card twice" or "my bank flagged a charge after I ordered from you" go straight to whoever looks after the site, the same day.

If one of those comes in, here's a reasonable first hour:

1. Reproduce it from a fresh private window, on a phone and a laptop. Write down the address you land on and take screenshots.
2. Switch off the likely suspects. Turn off the app embeds and storefront apps that can run code, starting with any that has something in a custom code box, and test again. Switching an app back on later is easy. Explaining a week of stolen card details isn't.
3. Lock those apps down. Change their passwords, require two-step sign-in and check who has access.
4. Tell the people who can act. Send what you found to the app's developer and to Shopify support. Report the look-alike address to Google Safe Browsing and URLhaus, as Zipp did.
5. Think about your customers. Ask your payment provider what to tell anyone who may have typed card details into the fake page, and get advice on whether you're required to notify anyone formally.

None of this needs a security team. It needs someone who knows which apps are on the store and is allowed to switch them off on a Saturday.

When we build or take over a store, the app list and who can change it are part of the job, not a cleanup for later. If you'd like a second pair of eyes on yours, our ecommerce work covers it, and you can tell us what you're running.

Related work: Paddle8.