Rate limiting

Un limitador cuenta peticiones contra una clave, compara la cuenta con un presupuesto en una ventana de tiempo y rechaza lo que se pase, normalmente con un HTTP 429 y una cabecera Retry-After. Las dos formas comunes son la ventana fija o deslizante, que es simple y da picos en el borde, y el cubo de tokens o cubo con fugas, que suaviza los picos porque los tokens se reponen a un ritmo fijo.

La decisión de diseño que importa es la clave. Limitar por dirección de origen cuenta el tráfico por posición de red. Limitar por cuenta cuenta los intentos por víctima. Limitar por credencial cuenta los intentos por contraseña. Limitar por operación cuenta trabajo caro en vez de peticiones. Un despliegue serio usa varias claves a la vez, y las aplica en el borde y otra vez en la aplicación, porque un atacante que llegue directamente a la aplicación se salta el borde.

El hallazgo de siempre es un limitador que solo usa como clave la dirección de origen, que es justo la clave que controla el atacante. Una tanda distribuida de credential stuffing reparte unos pocos intentos entre miles de direcciones y no lo dispara nunca. El password spraying lo derrota por el otro lado: una contraseña contra diez mil cuentas es un intento por cuenta, que tampoco ve ningún contador por cuenta. Lo que caza los dos es un límite de fallos por credencial y por tenant, más una señal de comportamiento.

Y luego está el truco de la cabecera. Si el limitador lee una cabecera de reenvío que el borde no sobrescribe, el atacante la pone a mano y reinicia su propio contador. Límites aplicados en el inicio de sesión pero no en el restablecimiento de contraseña, en el formulario web pero no en el endpoint móvil, y en la ruta REST pero no en su equivalente GraphQL son todas cosas que encontramos en el mismo parque.

Medimos el límite en vez de preguntar por él: enviamos peticiones hasta que el endpoint se niega, variamos la clave que podemos controlar y anotamos dónde está de verdad la frontera. El hallazgo nombra el endpoint, la clave, el umbral observado y qué cambió al rotar direcciones o cuentas. Un limitador que devuelve 429 pero sigue procesando la petición por debajo se informa como ausente. Esto forma parte de cómo sondeamos los controles de autenticación y de abuso de una API.