Guías de seguridad
Límite de peticiones y control de abusos: cómo diseñar límites que frenen la fuerza bruta y los costes desbocados
Limitar peticiones es decidir a quién cuentas, qué cuentas y qué pasa al llegar al tope. NIST fija 100 fallos consecutivos; OWASP incluye límites de gasto.
El límite de peticiones (rate limiting) suele fallar no porque el límite fuera demasiado laxo, sino porque se hizo la pregunta equivocada. Antes de decidir «cuántas por minuto», hay que responder tres preguntas: a quién cuentas, qué cuentas y qué pasa al llegar al tope.
Pregunta 1: ¿a quién cuentas?
Si la IP es el eje principal, falla tanto frente a atacantes como frente a usuarios legítimos
Del lado del atacante: detrás de un proxy inverso o una CDN, la dirección de origen que ve tu aplicación puede ser un valor escrito en una cabecera. Si confías sin condiciones en X-Forwarded-For, basta con reescribir una cabecera para contar como otra persona. Crees que estás contando y no cuentas nada. Hasta dónde se puede confiar en esa cabecera se explica en suplantación de X-Forwarded-For y proxies de confianza.
Del lado del usuario legítimo: el NAT de las empresas y las redes móviles hacen que muchos usuarios sin relación compartan una dirección. Si limitas por IP, restringes a gente que no te está atacando.
Por eso el eje principal debe ser un identificador ligado a quien actúa (una cuenta, una clave de API, una sesión establecida), con la IP como señal de apoyo. En las fases sin autenticar (antes del login) no hay un actor sobre el que contar, y eso es lo que tienen que cubrir las dos preguntas siguientes.
Pregunta 2: ¿qué cuentas?
Un diseño que solo cuenta peticiones no puede frenar una sola petición cara. El OWASP API Security Top 10 detalla qué necesita un tope en API4:2023 «Unrestricted Resource Consumption» (consumo de recursos sin restricciones).
Lo que cuentas
Peticiones: 100/min → por debajo del límite ✓
↓ pero lo que realmente se consume es
CPU · tiempo
un recorrido completo por llamada
Memoria
una entrada enorme
Ancho de banda
diez mil registros
Dinero
llamadas de pago repetidas
= agotado sin tocar nunca el tope
- Tiempo y memoria
- Tiempos máximos de ejecución, asignación máxima de memoria
- Recursos del sistema
- Número de descriptores de archivo, número de procesos
- Tamaño de entrada
- Tamaño máximo de los archivos subidos, tamaño máximo de los parámetros de entrada
- Trabajo por petición
- Número de operaciones realizadas en una sola petición del cliente de la API, registros devueltos por página
- Dinero
- Límites de gasto con proveedores externos e integraciones de API (ver más abajo; el último control contra el daño económico)
Respetar «100 peticiones por minuto» no protege nada si una petición devuelve diez mil registros, procesa un archivo enorme o hace varias llamadas a una API externa de pago. Ajusta la unidad que cuentas a lo que estás protegiendo: CPU, memoria, ancho de banda, dinero. Ese es el núcleo del diseño.
Pregunta 3: ¿qué pasa al llegar al tope?
Es la parte peor entendida. Más estricto no es automáticamente más seguro.
El efecto secundario de un bloqueo tosco
«Tres fallos y la cuenta queda congelada» parece lo correcto, pero también significa que un atacante puede congelar a propósito las cuentas de otros: has convertido el bloqueo en una herramienta de denegación de servicio contra tus propios usuarios. Frenaste la fuerza bruta entregando una forma de dejar fuera a la gente.
Diseñar para que «no compense»
Ralentiza los intentos en lugar de bloquear el acceso. Lo que enumera NIST SP 800-63B: exigir un CAPTCHA antes de autenticar, una espera tras cada intento fallido que crece a medida que la cuenta se acerca a su máximo permitido, una lista de direcciones IP desde las que el usuario ya se autenticó antes y técnicas basadas en riesgo o adaptativas que juzgan si el comportamiento está dentro de lo normal (dirección, ubicación, momento, metadatos del navegador).
La cifra de NIST es mayor de lo que esperas: 100 fallos consecutivos
NIST SP 800-63B establece que «el verificador DEBERÁ limitar los intentos de autenticación fallidos consecutivos en una sola cuenta a no más de 100». El conocido «bloquear tras tres» no es lo que pide la norma.
Por qué 100 es suficiente: una vez que hay retrasos y un CAPTCHA en el camino, llegar a 100 deja de ser práctico en un plazo útil. Dicho al revés: endurecer el número sin añadir ningún retraso es lo peor de ambos mundos, porque deja fuera a los usuarios legítimos y aun así permite que un ataque automatizado gaste sus intentos rápidamente.
Otra indicación práctica del mismo documento: tras una autenticación correcta, los verificadores DEBERÍAN ignorar los fallos anteriores de ese usuario desde la misma dirección IP. Decide también cuándo se reinicia el contador: forma parte del diseño.
Dónde aplicar cada cosa
Inicio de sesión (fuerza bruta y relleno de credenciales)
Usa como eje principal el contador de fallos por cuenta y aumenta el retraso de forma progresiva. Usa la IP como señal de apoyo, nunca como única base. Añadir autenticación multifactor hace que una contraseña correcta no dé acceso de inmediato, con lo que adivinar deja de compensar. Ten en cuenta también que las intrusiones recientes llegan cada vez más con credenciales válidas en lugar de adivinarlas (el análisis de vías de entrada de 2026, en inglés): el límite de peticiones es necesario, pero no suficiente.
Restablecimiento de contraseña y correos de confirmación (bombardeo de correo)
Cuenta tanto lo que puede provocar un envío como cuántos van al mismo destino. Un formulario que acepta la dirección de otra persona permite a un atacante acosar a un tercero y dañar a la vez tu reputación de envío. Combina un tiempo de espera por destino, un intervalo mínimo entre reenvíos y el borrado de los registros que quedan sin confirmar (lo que además reduce los datos personales no verificados que guardas). La vía de restablecimiento en sí se trata en fallos de diseño en el restablecimiento de contraseña.
Endpoints públicos y funciones de IA (picos de coste)
Cuenta el coste, no las peticiones. Limita el tamaño de entrada, las operaciones por petición y configura siempre el límite de gasto en el lado del proveedor. Entre los escenarios de OWASP hay una factura que pasa de 13 dólares al mes a 8.000. Cuando conectes una API externa de pago a una función pública, asegúrate de que haya una capa que aguante aunque tu propio código falle. Qué pasa cuando se filtra una clave se explica en una clave robada, una factura y una cuenta suspendida y en una clave de API filtrada desde código escrito por IA.
Operaciones caras (búsqueda, exportación, procesamiento de archivos)
Pon topes explícitos al tiempo de ejecución, la memoria, el tamaño de subida y los registros devueltos por página. Cualquier punto sin tope permite que una sola petición agote tus recursos. Limita también la memoria, la CPU y el número de procesos en la capa de contenedor o serverless, para que una aplicación que usa recursos inesperados se detenga desde fuera.
Entérate de cuándo se alcanza el tope
Un límite que no puedes observar es medio control. Si nadie ve que se está llegando al tope, no notarás ni un ataque en curso ni que se está dejando fuera a usuarios legítimos. Registra con qué frecuencia saltan los límites y avisa cuando haya un pico. Es el estado de «poder notar que algo va mal» de la base de seguridad para organizaciones, aplicado aquí.
La opinión de este sitio: el objetivo de un límite es que el abuso no compense
Si tratas el límite de peticiones como algo que bloquea los ataques por completo, acabas atascado en una pregunta sin respuesta: ¿cuántos intentos son seguros? Lo vemos de otra forma: se trata del coste y la ganancia del atacante. Sube el coste de cada intento para el atacante (tiempo, cálculo, CAPTCHA, un segundo factor) y baja la ganancia esperada de cada intento (probabilidad de acierto, hasta dónde llega con un acierto). No tienes que llevar la tasa de éxito a cero; tienes que hacer que no compense.
Por eso preferimos los retrasos y un segundo factor a un bloqueo duro. El dinero es el único caso en que ese razonamiento cambia: el único tope fiable es el límite de gasto que está fuera de tu propio código. El código a veces falla: pon un control fuera de tu código para que un error no pueda producir una factura sin límite.
Fuentes (primarias)
- NIST SP 800-63B, «Digital Identity Guidelines: Authentication and Lifecycle Management» §5.2.2 Rate Limiting (Throttling) — pages.nist.gov (el SHALL que limita los fallos consecutivos a no más de 100; CAPTCHA, esperas crecientes, listas de IP permitidas y técnicas basadas en riesgo; el SHOULD sobre ignorar los fallos anteriores desde la misma IP tras un acierto)
- OWASP API Security Top 10 2023, «API4:2023 Unrestricted Resource Consumption» — owasp.org (los recursos que necesitan límites, el impacto en costes y la configuración de límites de gasto con terceros)
Para seguir leyendo
- Comparación de los grandes casos de 2026: qué tienen en común KDDI, Aflac, la Agencia Digital y Sakura Internet (en inglés)
- Caso real: uso indebido del registro CPR de Dinamarca (en inglés; se abusó del acceso de consulta de un cliente legítimo)
- Caso real: brecha de Baitoru (hasta 3,88 millones de direcciones de correo) (en inglés; recolección masiva por un «fallo de especificación» y topes de registros por usuario)
- Requisito previo: suplantación de X-Forwarded-For y proxies de confianza (la base de «a quién cuentas»)
- Diseño: fallos de diseño en el restablecimiento de contraseña / cómo elegir la autenticación multifactor
- Coste: una clave robada, una factura y una cuenta suspendida / una clave de API filtrada desde código escrito por IA
FAQ
Q¿Con cuántos inicios de sesión fallidos debería bloquearse una cuenta: tres, cinco?
NIST SP 800-63B exige que el verificador limite los intentos de autenticación fallidos consecutivos en una sola cuenta a no más de 100. Tres o cinco no es un requisito de la norma. Lo que pide el mismo documento, para no bloquear a usuarios legítimos, es un CAPTCHA antes de autenticar, una espera que crece a medida que la cuenta se acerca a su máximo permitido, una lista de direcciones IP desde las que el usuario ya se autenticó antes y técnicas basadas en riesgo o adaptativas. Un bloqueo agresivo además da al atacante una forma de congelar a propósito las cuentas de otros. Sube el coste de cada intento en lugar de solo bajar el número.
Q¿Basta con limitar por dirección IP?
No. Detrás de un proxy inverso o una CDN, la dirección que ve tu aplicación puede no ser el origen real: si confías sin condiciones en X-Forwarded-For, un atacante se convierte en otro cliente con solo reescribir una cabecera, así que no estás contando nada. Y los usuarios legítimos comparten direcciones a través del NAT de empresas y de las redes móviles, así que los límites por IP también restringen a usuarios ajenos. Usa como eje principal un identificador ligado a quien actúa (cuenta, clave de API, sesión establecida) y trata la IP como señal de apoyo.
Q¿Cómo evito el bombardeo de correos de confirmación?
Necesitas a la vez un límite sobre quién puede provocar un envío y un recuento de cuántos van al mismo destino. Si tu formulario acepta la dirección de otra persona, un atacante puede usarte para acosar a un tercero y, al mismo tiempo, dañar la reputación de envío de tu dominio. Combina un tiempo de espera por dirección de destino, un intervalo mínimo entre reenvíos y el borrado de los registros que no se confirmaron tras un tiempo fijado, lo que además reduce los datos personales no verificados que guardas.
Q¿Cuál es el mayor peligro al poner una API de IA detrás de una función pública?
La factura. El OWASP API Security Top 10 enumera, en API4:2023 Unrestricted Resource Consumption, los límites que necesita una API (tiempos de ejecución, memoria, tamaño de subida, operaciones por petición) e incluye junto a ellos los límites de gasto con proveedores externos. Entre sus escenarios hay una factura que pasa de 13 dólares al mes a 8.000. Limitar el número de peticiones no te protege de operaciones que son caras de una en una. Configura el límite de gasto en el lado del proveedor: es el único tope que se mantiene aunque tu propio código falle.