Limitación de frecuencia por usuario, clave y origen

Un límite de frecuencia dice «tantas peticiones en tanto tiempo» y, sin que se note, añade una tercera parte: de quién. Esa parte es la clave de conteo, y puede ser la dirección de origen de la conexión, la clave de integración que manda el cliente, la cuenta de la sesión iniciada o el objeto sobre el que se actúa (un número de teléfono, un código emitido, un pedido). Cada clave responde a una pregunta distinta, y elegir la equivocada produce un límite que se cumple a rajatabla y no protege lo que tenía que proteger.

La dirección de origen es la clave más fácil de implementar porque la pasarela la tiene antes de leer nada más, y por eso es la que aparece por defecto. Pero detrás de una misma dirección puede haber una oficina entera, una red móvil o una cadena de tiendas, y una sola persona puede repartir sus peticiones entre muchas direcciones. El Top 10 de seguridad de APIs de OWASP de 2023 recoge esta familia de fallos en API4:2023, consumo de recursos sin restricción, y pide límites más estrictos justo en las operaciones sensibles, como validar un código de un solo uso o recuperar una contraseña.

Abre el laboratorio y lee limites-pasarela.yaml en la carpeta guanenta-frecuencia. Cada regla tiene una ruta, una clave de conteo, un límite y una ventana. Hazte con cada una la misma pregunta: lo que esta ruta protege, ¿a quién pertenece? El catálogo es igual para todo el mundo; los pedidos pertenecen a una integración; el segundo paso del inicio de sesión protege un código que pertenece a una sola cuenta.

Después cruza la regla con notas-equipo.txt: el código tiene seis dígitos, así que hay un millón de combinaciones, y vale diez minutos. Lo que decide si se puede adivinar no es cuántos intentos hace una dirección, sino cuántos recibe esa cuenta mientras el código está vivo.

Ahora el registro. En registro-pasarela.txt hay una ráfaga de verificaciones fallidas contra la cuenta cuya dueña recibió un código que no había pedido. Si todas hubieran salido de la misma dirección, la regla habría respondido 429 al undécimo intento; el resumen al final del archivo dice que no hubo ni uno. Cuenta las direcciones distintas desde las que llegaron esos intentos fallidos. Una de ellas aparece dos veces: cuenta direcciones, no líneas. No cuentes la otra cuenta del extracto, que falla una vez y acierta a la segunda: así se ve una persona que se equivoca al teclear.

MITRE describe la falta de este freno como CWE-307, restricción inadecuada de los intentos de autenticación excesivos. Aquí la restricción existe; lo que está mal es contra quién se cuenta.

La misma clave de conteo, en el otro sentido. La cadena de tiendas del extracto tiene una clave de integración por sede, pero el catálogo se cuenta por dirección y todas sus sedes salen a internet por una sola. La pasarela respondió como dice el estándar: el código 429, definido en la RFC 6585 para «demasiadas peticiones», con la cabecera Retry-After que dice cuánto esperar. La respuesta es correcta y el límite es el equivocado: para la pasarela, cinco sedes legítimas fueron un solo cliente que se pasó.

La regla general es que el límite se cuenta por lo que identifica a quien consume el recurso o a quien sufre el abuso, y que una ruta sensible puede llevar más de una clave a la vez. La dirección de origen sigue siendo útil como red de seguridad, para frenar avalanchas antes de que lleguen a la aplicación, pero no puede ser la única protección de algo que pertenece a una cuenta.