Adding rate limiting using express-rate-limit. Applied at the login route level with a 15-minute window and 5 attempts per IP.

Approach chosen: express-rate-limit (route-level)

Why this library: Minimal setup, battle-tested, integrates with Redis for distributed systems later. Alternatives considered: custom middleware (more control but reinventing the wheel), nginx-level rate limiting (more robust but out of scope).

Configuration decisions

• 15-minute window: Standard for auth endpoints. Short enough to mitigate brute force, long enough to not frustrate legit users with typos.
• 5 attempts: OWASP recommendation for login endpoints.
• IP-based keying: Changed to username+IP to prevent attackers rotating IPs. Trade-off: adds complexity, needed for real security.

What this does NOT protect against

• Distributed attacks across many IPs — needs a WAF for that
• Credential stuffing — needs breach detection (HaveIBeenPwned API)

Adding rate limiting using express-rate-limit...

What is rate limiting?

Rate limiting restricts how many requests a client can make in a time window. On auth endpoints, this stops brute-force attacks — where an attacker tries thousands of password combinations automatically.

How express-rate-limit works

The middleware intercepts each request, checks a counter for the client's IP, and either allows the request or returns a 429 Too Many Requests response. By default it stores counters in memory.

Key concept: rate limiting vs throttling

• Rate limiting: Hard block after X requests
• Throttling: Slow down responses instead of blocking

Learn more: expressjs.com/en/guide/using-middleware, OWASP auth testing guide.