The Shopping Cart Left Open: A Checklist for Weak Password Policies and Brute Force Attacks

As someone who audits shopping websites, I keep finding the same critical flaw again and again. The login page looks modern. The checkout flow is smooth. But underneath, the site allows unlimited login attempts and accepts password123 as a valid credential.

This is not a theoretical issue. I have seen customer accounts drained of gift card balances within hours of a brute force attack starting.

This post provides a practical checklist you can use to audit any shopping website for weak password policies and missing rate limiting. Use it to secure your own e-commerce project or to ethically disclose issues in others.

The Core Problem

Two failures must exist for this vulnerability to be critical:

First, the password policy is weak. The site accepts qwerty, iloveyou, or the store name followed by 123.

Second, there is no rate limiting. An attacker can send hundreds of login attempts per minute without triggering a block, a CAPTCHA, or an account lockout.

When both conditions are true, any customer account can be taken over through brute force. The business impact includes stolen payment methods, fraudulent orders, and chargeback losses.

The Checklist

I have broken the audit into five sections. Work through these in order.

Part 1: Password Policy Assessment

Test these during account creation or password change.

1. Can you register with a single character password such as a?
2. Can you register with a numeric only password such as 12345678?
3. Can you register with a common weak password such as password or welcome?
4. Does the system enforce a minimum length of at least eight characters?
5. Does the system require at least three of four character types including uppercase, lowercase, number, and symbol?
6. Does the system reject passwords containing the email username or the store name?
7. Does the system check against a known breached password list like the top ten thousand from rockyou.txt?
8. Is the same weak policy enforced for admin account creation?

A fail on any of these indicates a weak policy.

Part 2: Rate Limiting on the Login Endpoint

Test the primary login form and any API login endpoints.

1. Send five rapid login attempts with a wrong password. Is there any delay or block?
2. Send twenty rapid attempts. Do any fail with an HTTP 429 status code indicating too many requests?
3. Send one hundred attempts over sixty seconds from the same IP address. Does any lockout occur?
4. Send ten attempts for the same username from different IP addresses. Does the account lock?
5. Is a CAPTCHA presented after three failed attempts?
6. If a CAPTCHA exists, is it weak such as a simple math question or an easily parsed image?
7. Does rate limiting reset after a successful login from a different IP address?
8. Are login attempts logged with a timestamp and source IP address?

A pass requires clear evidence of progressive restrictions.

Part 3: Account Lockout and Notifications

These controls protect individual accounts after abuse is detected.

1. Does the account lock after ten failed login attempts?
2. Is the lockout temporary, such as fifteen minutes, or permanent requiring admin intervention?
3. Does the user receive an email notification after five or more failed attempts?
4. Does the forgot password flow bypass rate limiting? Test rapid forgot password requests.
5. Does the resend verification email endpoint have its own rate limiting?

Shopping websites often secure the main login but forget these related flows.

Part 4: Brute Force Resistance of Related Endpoints

Attackers will not limit themselves to the login page.

1. Is the gift card balance check endpoint unlimited? Test rapid sequential guesses.
2. Is the coupon code validation endpoint unlimited? Attackers can enumerate working discount codes.
3. If two factor authentication is enabled, are unlimited OTP attempts allowed?
4. Is the password reset token endpoint vulnerable to brute force guessing?
5. Does the API login endpoint used by the mobile app enforce the same rate limits as the web login?

I have found that mobile API endpoints are the most common missing piece.

Part 5: Response Information Leakage

Even with strong rate limiting, information leaks help attackers.

1. Does the login response differ meaningfully between user not found and wrong password?
2. Does the error message reveal whether an account is locked?
3. Does the response time differ between existing and non existing users? This creates a timing attack.
4. Are login endpoints accessible over plain HTTP instead of HTTPS?

A generic message such as Invalid email or password is the safe choice.

How to Present Findings to a Client

When I deliver this checklist to an e-commerce client, I include a one page executive summary with three sections.

First, state the business impact. An attacker can brute force customer accounts and place fraudulent orders. The merchant absorbs chargeback losses and reputation damage.

Second, provide the raw score. For example, 18 out of 30 checks failed, resulting in high severity.

Third, give a remediation timeline in plain language.

Immediate actions within 48 hours include adding a CAPTCHA after three failed logins, rate limiting to five attempts per fifteen minutes per IP address, and enforcing HTTPS on all login endpoints.

Short term actions within one week include setting a minimum password length of twelve characters, requiring three of four character types, and adding email alerts after five failed login attempts.

Medium term actions within two to four weeks include implementing an account lockout after ten attempts, blocking the top ten thousand common passwords, and applying rate limiting to the forgot password, gift card, and coupon endpoints.