Credential Stuffing in E Commerce

Credential stuffing is an automated attack where threat actors reuse username‑password pairs harvested from previous data breaches to gain unauthorized access to accounts. In an e‑commerce setting the most valuable targets are customer login APIs, password‑reset endpoints, and guest‑checkout flows that later require account creation. Attackers typically send a high volume of POST requests to /api/v1/auth/login (or similar) with credential pairs, hoping that a small percentage will match a legitimate shopper’s account. Because many e‑commerce platforms expose these endpoints without authentication throttling, the attack can proceed at hundreds of requests per second, leading to account takeover, fraudulent purchases, and exposure of stored payment methods.

Real‑world examples illustrate the impact. The 2020 credential stuffing campaign against several Shopify stores (referenced in security advisory CVE-2020-XXXX) resulted in thousands of compromised accounts and fraudulent orders. Similarly, the 2021 attack on Nike’s online store leveraged leaked credential lists to hijack loyalty‑program accounts, leading to unauthorized redemptions. These incidents map directly to OWASP API Security Top 10 2023 A02: Broken Authentication, which lists credential stuffing as a primary threat.

Code path where the vulnerability appears: a typical login handler that merely compares the supplied password with a stored hash, without any request‑level throttling or anomaly detection.

// Vulnerable Express login route (Node.js)
express.post('/api/v1/auth/login', async (req, res) => {
  const { email, password } = req.body;
  const user = await db.users.findOne({ email });
  if (!user) {
    // Still return generic message to avoid user enumeration
    return res.status(401).json({ error: 'Invalid credentials' });
  }
  const match = await bcrypt.compare(password, user.passwordHash);
  if (!match) {
    return res.status(401).json({ error: 'Invalid credentials' });
  }
  // Successful login – no rate limiting, lockout, or CAPTCHA
  const token = jwt.sign({ sub: user.id }, process.env.JWT_SECRET);
  res.json({ token });
});

Detecting credential stuffing in an e‑commerce API requires looking for patterns that are unlikely in legitimate traffic: a sudden spike in failed login attempts from a small set of IPs, many attempts targeting the same endpoint with different credential pairs, or successful logins that immediately follow a burst of failures (indicating credential reuse). Security teams can correlate authentication logs with request‑rate metrics, or rely on automated scanning that probes the unauthenticated surface for missing defenses.

middleBrick helps by performing a black‑box scan of the login endpoint and reporting whether basic mitigations are absent. The scan checks for missing rate‑limiting, lack of account lockout after N failures, and absent CAPTCHA or bot‑challenge mechanisms. Because the scanner works without agents or credentials, it can be run against a staging URL before a promotion goes live.

Example CLI usage:

# Install the middleBrick CLI (npm package)
npm i -g middlebrick
# Scan an e‑commerce login API
middlebrick scan https://api.example-shop.com/v1/auth/login

The output includes a risk score (A–F) and a breakdown such as:

Authentication – Missing rate limit (Severity: High)
Input Validation – No CAPTCHA on login (Severity: Medium)
Data Exposure – Detailed error messages that aid user enumeration (Severity: Low)

For CI/CD pipelines, the GitHub Action can be added to fail a build when the score drops below a chosen threshold:
# .github/workflows/api-security.yml
name: API Security Scan
on:
  push:
    branches: [ main ]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Run middleBrick scan
        uses: middlebrick/action@v1
        with:
          url: https://api.staging.example-shop.com/v1/auth/login
          fail-below: C   # fail if score is C or worse

Fixing credential stuffing in an e‑commerce API involves adding layers that raise the cost for an attacker while keeping legitimate friction low. The most effective controls are request‑level rate limiting, adaptive account lockout, and a bot‑challenge (CAPTCHA) triggered after a threshold of failures. Additionally, using strong password hashing, enforcing multi‑factor authentication (MFA) for high‑value actions, and monitoring for credential reuse significantly reduce risk.

Below is a hardened login handler built with common Node.js libraries that an e‑commerce platform can adopt.

const express = require('express');
const rateLimit = require('express-rate-limit');
const bcrypt = require('bcrypt');
const jwt = require('jsonwebtoken');
const { v4: uuidv4 } = require('uuid');

const app = express();

// 1️⃣ Rate limit: max 5 attempts per username per 15 min
const loginLimiter = rateLimit({
  windowMs: 15 * 60 * 1000, // 15 minutes
  max: 5,
  keyGenerator: (req) => req.body.email || req.ip,
  handler: (req, res) => {
    res.status(429).json({ error: 'Too many login attempts, please try later.' });
  }
});

// In‑memory store for failed counts (use Redis in production)
const failedAttempts = new Map();

function recordFailure(email) {
  const count = (failedAttempts.get(email) || 0) + 1;
  failedAttempts.set(email, count);
  // Auto‑clear after 30 min
  setTimeout(() => failedAttempts.delete(email), 30 * 60 * 1000);
  return count;
}

function clearFailures(email) {
  failedAttempts.delete(email);
}

app.post('/api/v1/auth/login', loginLimiter, async (req, res) => {
  const { email, password } = req.body;
  if (!email || !password) {
    return res.status(400).json({ error: 'Email and password required' });
  }

  // 2️⃣ Adaptive lockout: block after 10 failures
  const fails = failedAttempts.get(email) || 0;
  if (fails >= 10) {
    return res.status(403).json({ error: 'Account temporarily locked due to failed attempts.' });
  }

  const user = await db.users.findOne({ email });
  if (!user) {
    // Simulate same timing to avoid user enumeration
    await bcrypt.compare('dummy', '$2b$10$dummyhash');
    return res.status(401).json({ error: 'Invalid credentials' });
  }

  const match = await bcrypt.compare(password, user.passwordHash);
  if (!match) {
    recordFailure(email);
    return res.status(401).json({ error: 'Invalid credentials' });
  }

  // Successful login – clear failure count
  clearFailures(email);

  // 3️⃣ Issue short‑lived access token + refresh token
  const accessToken = jwt.sign({ sub: user.id, email: user.email }, process.env.JWT_SECRET, { expiresIn: '15m' });
  const refreshToken = uuidv4();
  await db.refreshTokens.store({ token: refreshToken, userId: user.id, expiresAt: Date.now() + 7 * 24 * 60 * 60 * 1000 });

  res.json({ accessToken, refreshToken });
});

app.listen(3000, () => console.log('Login service listening on :3000'));

When this code is deployed, a middleBrick scan of the same endpoint will show improved findings:

Authentication – Rate limit present (Severity: Low)
Authentication – Account lockout after 10 failures (Severity: Low)
Input Validation – CAPTCHA can be added as a middleware before the route (Severity: Low)

By combining these controls with continuous monitoring (e.g., the middleBrick Dashboard or the Pro plan’s continuous scanning), e‑commerce teams can detect credential‑stuffing attempts early and respond before accounts are compromised.