CWE-307 in APIs

CWE-307 describes a weakness where an application does not implement sufficient measures to prevent repeated authentication attempts. This allows attackers to systematically guess passwords or other credentials through brute force or dictionary attacks. The weakness manifests when systems lack rate limiting, account lockout mechanisms, or exponential backoff for failed login attempts.

Attackers exploit this by automating credential guessing at scale, often using tools that can test thousands of combinations per minute. Without proper restrictions, they can eventually discover valid credentials through sheer volume of attempts, compromising user accounts and potentially gaining unauthorized access to sensitive systems.

APIs are particularly vulnerable to CWE-307 because they're designed for machine-to-machine communication, making them ideal targets for automated credential stuffing attacks. Unlike traditional web applications with CAPTCHAs or rate limits per IP, APIs often lack these protections or have them implemented incorrectly.

Common API manifestations include:

• Authentication endpoints that accept unlimited login attempts without delays
• Token refresh endpoints vulnerable to brute force of refresh tokens
• Multi-factor authentication bypass due to lack of attempt tracking across factors
• Password reset endpoints allowing enumeration of valid usernames
• JWT token generation endpoints without rate limiting

APIs also face unique challenges because attackers can distribute attempts across multiple IP addresses, rotate user agents, and use botnets to circumvent simple IP-based rate limiting. The stateless nature of many API authentication systems makes tracking and limiting attempts more complex than in traditional web applications.

Detecting CWE-307 requires both manual testing and automated scanning. Manual testing involves systematically attempting multiple failed authentications while monitoring response times and error messages. Look for patterns like consistent response times regardless of attempt count, lack of account lockout after numerous failures, or informative error messages that distinguish between invalid usernames and passwords.

Automated tools like middleBrick scan APIs for this weakness by testing authentication endpoints with invalid credentials and measuring the system's response characteristics. The scanner evaluates whether authentication endpoints implement proper rate limiting, detect credential stuffing patterns, and provide appropriate feedback without revealing sensitive information.

middleBrick's authentication scanning specifically tests for:

• Rate limiting implementation on login endpoints
• Account lockout mechanisms after failed attempts
• Exponential backoff in response to repeated failures
• Consistent error messaging that doesn't leak valid username information
• Multi-factor authentication endpoint protections

The scanner provides a security score and detailed findings, showing whether authentication endpoints properly restrict excessive attempts and what specific vulnerabilities exist.

Effective remediation requires implementing multiple layers of protection. Here are code-level examples for common API authentication scenarios:

// Node.js/Express example with rate limiting
const rateLimit = require('express-rate-limit');

const loginRateLimiter = rateLimit({
  windowMs: 15 * 60 * 1000, // 15 minutes
  max: 5, // limit each IP to 5 requests
  message: 'Too many login attempts, please try again later.',
  keyGenerator: (req) => req.ip + ':' + req.body.username
});

app.post('/api/login', loginRateLimiter, async (req, res) => {
  // authentication logic
});

Key implementation strategies:

1. Rate Limiting: Implement sliding window rate limiting on authentication endpoints, tracking both IP addresses and usernames to prevent distributed attacks.
2. Account Lockout: Lock accounts after a configurable number of failed attempts (typically 3-5), with increasing lockout durations.
3. Exponential Backoff: Introduce progressively longer delays between allowed attempts after each failure.
4. Consistent Error Messages: Return identical responses for all authentication failures to prevent username enumeration.
5. Multi-Factor Protection: Apply rate limiting across all authentication factors, not just the first factor.

Additional security measures include implementing CAPTCHA after threshold breaches, using challenge-response mechanisms, and logging all authentication attempts for monitoring and alerting.