Account takeover attacks and bot traffic are quieter than a headline data breach, but they steadily drain loyalty points, stored payment methods and customer trust. Here's how the attacks work and what actually stops them.
How account takeover attacks work
Account takeover (ATO) happens when a criminal gains access to a genuine customer's account on your site — usually not by hacking you directly, but by using email and password combinations leaked in breaches of entirely unrelated services. Because so many people reuse passwords across sites, a leak at one retailer or app can hand attackers working credentials for accounts on your store months or years later.
Once inside an account, attackers typically change the delivery address, use any stored payment method or loyalty balance, and place orders before the genuine customer notices — leaving you liable for the loss and the customer with a damaging experience that erodes trust in your brand even though the fault lies elsewhere.
What credential stuffing looks like from the outside
Credential stuffing is the automated version of this attack: bots attempt thousands or millions of leaked username/password combinations against your login page in rapid succession, looking for matches. Signs include a sudden spike in failed login attempts, logins attempted against email addresses that don't exist in your customer database, and login traffic concentrated from data centre IP ranges rather than typical residential or mobile connections.
- A sharp, sustained rise in login attempts outside normal traffic patterns.
- An unusually high ratio of failed to successful logins.
- Logins spread across many accounts from a small number of IP addresses.
- Successful logins immediately followed by a password or address change.
Practical defences against credential stuffing
Rate limiting login attempts — locking an account or IP address out after a handful of failed attempts within a short window — is the single most effective and cheapest defence, and is supported natively or via a plugin on every major e-commerce platform. CAPTCHA or an invisible bot-detection challenge on the login form filters out the vast majority of automated attempts without meaningfully inconveniencing genuine customers.
Encourage or require stronger passwords at account creation, and consider integrating a breached-password check (services like Have I Been Pwned offer a free API) that blocks customers from setting a password already known to be compromised elsewhere. Two-factor authentication as an optional or required step for customer accounts, particularly those with stored payment methods, closes the door even when a password has been compromised.
Managing bad bot traffic beyond login pages
Bots don't only target login pages — scraper bots harvest your pricing and product catalogue for competitors, inventory-hoarding bots add limited-stock or discounted items to cart without purchasing to frustrate genuine buyers, and scalper bots buy up high-demand, limited-release products for resale. A web application firewall (WAF) with bot management — available through Cloudflare, AWS WAF, or built into platforms like Shopify Plus — identifies and blocks non-human traffic patterns before they reach your application.
Responding when an account has been compromised
Build a clear internal process for handling a reported or detected account takeover: immediately lock the affected account, reverse any unauthorised orders where possible, notify the genuine customer through a verified channel (not the email address on the compromised account, which may have been changed by the attacker), and force a password reset before restoring access. Keep a log of these incidents — a cluster of takeovers in a short period may indicate a wider credential-stuffing campaign against your site specifically, which is useful evidence for your payment processor and, if data was exposed, potentially the ICO.
Educating customers without shifting all the blame
While password reuse is fundamentally a customer behaviour issue, you can reduce your exposure by prompting customers to use a unique password at signup, offering (or requiring) 2FA for accounts with saved payment details, and sending an automatic notification whenever account details like email, password or delivery address are changed, so genuine customers are alerted quickly if a change wasn't theirs.
A short, plain-English account security page — explaining what 2FA is, why it matters, and how to enable it in a couple of clicks — measurably increases adoption compared with simply offering the option buried in account settings. Pairing this with a periodic reminder email to customers who haven't enabled 2FA on an account holding saved payment details closes a meaningful share of the gap without requiring any new technology investment on your part.
How This Connects to the Rest of Your Operation
It's rarely useful to treat protecting your online store against account takeover attacks, credential stuffing and bots as a standalone decision — the strongest results tend to come from lining it up with the rest of your operation. Many of the same principles come up again in Business Interruption Insurance for Online Retailers: Protecting Revenue When Trading Stops, which is worth bookmarking for later.
For related reading: We cover this in more detail in Protecting Your IP and Product Designs When Sourcing Overseas, which is worth reading alongside this piece. For the practical mechanics, see Managing Amazon Seller Performance Metrics and Account Health.