No Account Lockout / Brute Force Protection
Login endpoints with no rate limiting or lockout mechanism, allowing attackers to try unlimited username and password combinations until they find valid credentials.
How It Works
A brute force attack tries thousands of passwords per second. Without rate limiting, an attacker can test the entire RockYou wordlist (14 million passwords) against your login endpoint in minutes. Credential stuffing — trying username/password pairs from other breaches — is equally effective and automated.
// BAD: login with no rate limiting
export async function POST(req: Request) {
const { email, password } = await req.json();
const user = await db.users.findByEmail(email);
if (!user || !bcrypt.compare(password, user.passwordHash)) {
return Response.json({ error: 'Invalid credentials' }, { status: 401 });
}
return Response.json({ token: generateToken(user) });
}// GOOD: rate limit login attempts
import { Ratelimit } from '@upstash/ratelimit';
const ratelimit = new Ratelimit({ limiter: Ratelimit.slidingWindow(5, '15m') });
export async function POST(req: Request) {
const ip = req.headers.get('x-forwarded-for') ?? 'anonymous';
const { success } = await ratelimit.limit(ip);
if (!success) return Response.json({ error: 'Too many attempts' }, { status: 429 });
// ... rest of login logic
}Real-World Example
The 2016 LinkedIn credential stuffing attack used 117 million leaked credentials to attempt login across other services. Apps without rate limiting saw massive unauthorized access. Automated tools like Sentry MBA make this trivially easy.
How to Prevent It
- Implement rate limiting on login endpoints — 5 attempts per 15 minutes per IP is a common baseline
- Add progressive delays after failed attempts (exponential backoff)
- Consider CAPTCHA after 3+ failed attempts for the same email
- Use Upstash Rate Limit, express-rate-limit, or your API gateway's built-in protection
- Alert on unusual login patterns (many failures, logins from new countries)
Affected Technologies
Data Hogo detects this vulnerability automatically.
Scan Your Repo FreeRelated Vulnerabilities
Session Fixation
highThe server reuses the same session ID before and after login, allowing an attacker who planted a known session ID to hijack the authenticated session.
Weak Password Policy
mediumNo minimum length, complexity, or common-password requirements on registration or password change, making user accounts easily brute-forced or guessed.
OAuth State Parameter Missing
highOAuth authorization flow implemented without a random `state` parameter, allowing CSRF attacks that link a victim's account to the attacker's OAuth identity.
Token Not Invalidated on Logout
mediumJWT or session tokens remain valid after a user logs out because there is no server-side revocation mechanism, allowing stolen tokens to be used indefinitely.