Rate Limiting and Brute-Force Protection: Securing Login and API Endpoints

Rate limiting caps how many requests a client can make in a given period. Simple as it sounds, it is a fundamental defence across a broad range: from brute-force password attempts to API abuse, resource exhaustion and scraping. This article covers where and how to apply it, and the pitfalls to avoid.

What it protects

• Brute force and credential stuffing: slowing attempts on login and password-reset endpoints raises the attacker’s cost.
• API abuse: protecting costly operations (SMS sending, search, export) from excessive calls.
• Resource exhaustion: a basic application-level DoS mitigation.
• Scraping: slowing bulk data extraction.

How to apply it

1. Apply stricter limits to sensitive endpoints. Login, registration, password reset and OTP verification should be limited more tightly than general traffic.
2. Key on the right identifier. Limiting by IP alone can punish many legitimate users behind NAT or miss an IP-rotating attacker; where possible combine account/session + IP.
3. Respond gradually. First throttle (delay), then temporary lockout; sudden permanent blocks can hit legitimate users.
4. Return 429 Too Many Requests and Retry-After.
5. Use a central counter in distributed setups. With multiple servers, limits must be shared (e.g., a central cache); otherwise each server counts separately and the limit effectively multiplies.

Common mistakes

• Client-side only limiting: real protection is server-side.
• A single global limit: the login endpoint should not share a limit with static content.
• Abusable lockout: a “lock the account after 5 failures” rule lets an attacker deliberately lock others out (a lockout DoS); gradual delay + MFA is more balanced.

Summary

Rate limiting is a shared, low-cost defence against many attacks. Effective application: strict limits on sensitive endpoints, keying on the right identifier, gradual response (429 + Retry-After), and a central counter in distributed environments. Design lockout mechanisms so they cannot be abused.

Sources: OWASP: Blocking Brute Force Attacks, MDN: 429 Too Many Requests.

Are rate limits correctly configured on your login and API endpoints? CyberTestify’s active verification assesses this on discovered endpoints.