Express.js
Explica cómo limitar requests por identidad, IP, ruta o coste y combinar cuotas, ventanas, almacenamiento compartido y respuestas 429 frente al abuso.
Rate limiting limita frecuencia o consumo dentro de una ventana. No sustituye autenticación, autorización, límites de payload, timeouts ni capacidad del sistema.
Una política responde:
quién consume
+ qué recurso consume
+ cuánto puede consumir
+ durante qué periodo
→ permitir o rechazarLa clave puede ser IP, usuario, API key, tenant, endpoint o una combinación.
Ayuda a reducir:
No detiene por sí solo un ataque distribuido grande ni una request individual extremadamente costosa.
Cuenta requests por intervalo. Es simple, pero permite bursts en el borde entre ventanas.
Considera actividad reciente con más precisión. Requiere más estado.
Acumula tokens hasta una capacidad y consume por operación. Permite bursts controlados y una tasa sostenida.
Suaviza salida a una tasa constante, útil para colas o proveedores.
Disponible antes del login, pero NAT comparte usuarios e IPv6 permite rotación. Detrás de proxy depende de trust proxy.
Útil para login y uso autenticado, pero no debe revelar si la cuenta existe.
Adecuado para integraciones.
Protege fair usage, aunque puede castigar a todos por un actor abusivo.
Combina niveles: IP + cuenta en login; tenant + actor en endpoints autenticados.
No todas las requests cuestan igual. Una exportación puede consumir 100 unidades y un health check 1. Un modelo de cuotas puede reflejar:
Un contador en memoria funciona en una instancia, pero se divide al escalar. Opciones:
El store también puede fallar. Define fail-open o fail-closed según riesgo. Login puede preferir protección estricta; una lectura pública quizá degrade.
HTTP/1.1 429 Too Many Requests
Retry-After: 30Puedes añadir headers estandarizados de rate limit si el ecosistema los soporta. No reveles información que facilite evadir controles.
const loginLimiter = rateLimit({
windowMs: 15 * 60 * 1000,
limit: 10,
keyGenerator(request) {
return `${request.ip}:${normalizeLoginIdentifier(request.body?.email)}`;
},
standardHeaders: true,
legacyHeaders: false,
});El ejemplo necesita un parser limitado antes, redacción de email y trust proxy correcto. En producción, evita almacenar identificadores personales en claro en las keys; usa hash con secreto cuando corresponda.
Límite por IP y cuenta, respuestas uniformes, backoff y alertas.
Evita spam y enumeración; responde de forma indistinguible.
Limita tasa y complejidad.
Limita frecuencia y bytes.
Conviene cuota y job asíncrono.
No bloquees un proveedor legítimo por bursts sin conocer su retry policy; autentica firma y escala recepción.
Rate limit controla requests por tiempo. Concurrency limit controla cuántas operaciones costosas pueden estar activas a la vez. Ambos pueden ser necesarios.
Un usuario puede respetar 10 requests/minuto y aun así abrir 10 exports de 5 minutos.
La app puede ver la IP del proxy. Configura headers confiables.
Limitar por dirección completa puede permitir evasión con prefijos. Usa estrategia compatible con privacidad y red.
Algoritmos distribuidos dependen del reloj. Stores centrales o timestamps consistentes reducen diferencias.
Un Retry-After idéntico para todos puede sincronizar reintentos. Los clientes deberían añadir jitter.
Define métricas y comportamiento explícito; no ignores silenciosamente.
Retry-AfterLímites estrictos protegen capacidad, pero pueden afectar usuarios legítimos. Stores compartidos mejoran precisión, pero añaden latencia y dependencia. Enforcement en gateway reduce carga de app, aunque necesita identidad disponible allí.
Payload limits y resource exhaustion protege memoria, CPU, pools y trabajo generado por una sola request.