"Why does this customer's order say it's shipping to an address in another country, and why did their saved card get changed yesterday?" That was the support ticket that landed on a homeware store's desk on a Tuesday morning. The customer hadn't logged in for months. Someone else had – using a password that turned out to be identical to one leaked in an unrelated breach three years earlier. By the time the team caught it, the attacker had already placed one order and tried a second. This is account takeover, and it's one of the most common – and most preventable – fraud categories online stores face.
The Support Ticket That Reveals a Bigger Problem
Account takeover (ATO) rarely announces itself. It shows up as a support ticket, a chargeback, or a customer complaint about loyalty points that vanished. By the time it's visible, the damage – a fraudulent order, a drained gift card balance, a customer who no longer trusts the store – is already done. The fix isn't a single tool; it's a set of layered controls that make each stage of an attack harder to pull off.
What Account Takeover Actually Looks Like in PrestaShop Stores
Credential Stuffing at the Login Form
Most ATO starts with credential stuffing: attackers run lists of leaked email/password combinations against a store's login page, betting that some customers reused a password from another breached site. A login form with no rate limiting can be tested thousands of times an hour without raising any alarm. For broader context on how this fits into the wider threat picture, see /blog/future-cybersecurity-threats-ecommerce/.
Session Hijacking and Cookie Theft
Even a strong password doesn't help if an active session can be stolen – through an unsecured network, a cross-site scripting flaw, or malware on the customer's device. Session cookies without the Secure and HttpOnly flags, or sessions that never expire, extend the window an attacker has to act.
Password Reset Abuse
Password reset flows are a favorite target because they bypass the password entirely. If a reset link doesn't expire quickly, isn't tied to the requesting device, or leaks account existence through error messages ("no account found" vs a generic message), attackers can use it to take over accounts without ever guessing a password.
Why Passwords Alone Won't Hold in 2026
Passwords, even "strong" ones, are a single point of failure shared across dozens of sites the average customer uses. A breach anywhere in that chain compromises the password everywhere it's reused – which, by most industry estimates, is a majority of users for at least some of their accounts. That's the structural reason MFA and passkeys keep coming up as the most effective single upgrade a store can make.
Layered Defenses That Work
Multi-Factor Authentication and Passkeys
MFA adds a second proof of identity – a one-time code, a push notification, or a hardware key – so a leaked password alone isn't enough. Passkeys, built on the WebAuthn standard, go further by removing shared secrets entirely: the credential is tied to the device and can't be phished or reused across sites. Offering passkeys as an option for customer accounts, and requiring MFA for every back-office account, closes the largest gap most stores have.
Rate Limiting and Bot Mitigation
A simple rule – lock out or slow down after five failed attempts from the same IP or account within a short window – blunts credential stuffing without much engineering effort. Pair it with a CAPTCHA or a bot-detection service on login, registration, and password reset endpoints, since those three forms attract the bulk of automated abuse.
Device Fingerprinting and Anomaly Detection
Flagging logins from a new device, unfamiliar country, or unusual hour – and requiring a step-up verification when that happens – catches attackers even when they have a valid password. This doesn't need to be intrusive for legitimate customers; a simple email confirmation for new-device logins is often enough.
Breach Password Checks
Checking new and existing passwords against known breach databases (via a service like the Have I Been Pwned API) at signup or password change lets you block reuse of already-compromised credentials before an attacker gets the chance.
What Detection Actually Looks Like Day to Day
None of this needs to be dramatic. In practice it's a dashboard that flags "17 failed logins on this account in the last hour" or "this session just changed the payment method and shipping address within 90 seconds of logging in from a new country." Those two signals together are a far stronger fraud indicator than either alone, and most stores already have the raw log data to build that rule – they just haven't wired it into an alert yet.
The Real Cost When Account Takeover Goes Unnoticed
Beyond the immediate fraudulent order, a successful takeover erodes something harder to rebuild: the customer's trust that their saved card and address were actually safe. A customer who discovers a stranger placed an order on their account rarely comes back quietly, even after a refund. Chargeback fees, refund processing, support time, and the quieter cost of customer churn all stack up faster than the size of any single fraudulent order would suggest – which is exactly why the layered defenses below are worth the setup time even for a smaller store.
MFA Methods Compared
| Method | Phishing Resistant | Customer Friction | Best Use Case |
|---|---|---|---|
| SMS one-time code | No | Low | Basic customer accounts, better than nothing |
| Authenticator app (TOTP) | Partial | Medium | Staff and admin accounts |
| Push notification | Partial | Low | High-value customer accounts |
| Passkeys (WebAuthn) | Yes | Low after setup | Long-term customer and admin accounts |
| Hardware security key | Yes | Medium | Admin and finance staff |
Session Security Configuration Basics
A few server-side settings meaningfully reduce session hijacking risk:
Set-Cookie: PrestaShop-XXXX; Secure; HttpOnly; SameSite=Strict
Session timeout: 30 minutes idle for customer accounts
Session timeout: 15 minutes idle for back-office admin accounts
Regenerate session ID on login and privilege changeThese are small changes, but they close the window an attacker has if a session token is ever exposed.
An Account Takeover Hardening Checklist
- [ ] Require MFA on all back-office and admin accounts
- [ ] Offer passkey login for customer accounts
- [ ] Rate-limit login, registration, and password reset endpoints
- [ ] Set Secure, HttpOnly, and SameSite flags on session cookies
- [ ] Check new passwords against known breach databases
- [ ] Alert on and require step-up verification for new-device logins
- [ ] Use generic error messages on login and reset forms to avoid account enumeration
- [ ] Review and shorten password reset link expiry windows
Frequently asked questions
Related reading
- Future Cybersecurity Threats Facing eCommerce
- How Zero Trust Security Can Protect eCommerce Businesses
- Preventing Fake Orders with AI
- AI Fraud Detection for Online Stores
- GDPR Security Best Practices Beyond Compliance
