Limitación de solicitudes y protección contra fuerza bruta

Without limits, attackers can hammer your login endpoint to guess passwords, scrape data, or run up costs on metered APIs. Rate limiting caps how many requests a client can make in a window.

Limits are keyed on something that identifies the caller: an IP address, a user ID, or an API key. Choose the key based on what you are protecting.

The simplest method counts requests per fixed time window. If the count exceeds the limit, reject until the window resets.

Redis is ideal: INCR bumps a counter atomically, and a TTL auto-expires the window. The first request sets the expiry.

Fixed windows allow bursts at the edges. Sliding window smooths this, and token bucket permits short bursts while enforcing an average rate. Libraries like Upstash Ratelimit implement these for you.

Centralize limiting in Next.js middleware so it runs before every matched request.

When limited, respond with status 429 and a Retry-After header telling clients when to try again.

For login specifically, track failed attempts per account. After several failures, temporarily lock the account to stop targeted brute force.

Increase the delay after each failure: 1s, 2s, 4s, 8s. This frustrates automated guessing while barely affecting legitimate users.

Be careful not to punish real users:

• Shared office IPs share a limit — prefer per-user keys when authenticated
• Reset counters on success
• Set generous limits for normal usage

Protect endpoints well:

• Key limits on IP, user, or API key
• Use Redis with sliding window or token bucket
• Return 429 with Retry-After
• Add lockout and backoff for login

You learned to defend against abuse:

• Key rate limits on IP, user, or API key
• Count with Redis INCR and TTL, or use sliding window libraries
• Return 429 with Retry-After
• Add account lockout and exponential backoff for logins

Your auth and APIs now resist brute force and flooding.