Tema 15
Una API segura no solo decide quién puede acceder, sino también cuánto puede consumir cada actor, con qué velocidad y bajo qué condiciones. Sin controles de volumen y ritmo, una API queda expuesta a scraping, fuerza bruta, automatización agresiva, degradación operativa y costos desproporcionados incluso cuando todas las solicitudes son técnicamente válidas.
Una API está diseñada para recibir tráfico. El problema no es el uso, sino el uso descontrolado. Si cualquier actor puede enviar un volumen alto de solicitudes, mantenerlas a gran velocidad o disparar operaciones costosas sin restricciones, la API queda vulnerable a abuso, degradación y denegación de servicio.
Este problema no siempre se manifiesta como un ataque ruidoso. A veces toma la forma de scraping constante, intentos de login distribuidos, consultas pesadas repetidas o consumo legítimo técnicamente válido pero desproporcionado respecto al objetivo del sistema.
Por eso, controlar el ritmo y la cantidad de consumo es una parte central de la seguridad en APIs REST.
Rate limiting, cuotas y throttling ayudan a responder preguntas como estas:
Estas decisiones protegen no solo la infraestructura, sino también el negocio: evitan automatización abusiva, reducen impacto de errores de cliente y limitan oportunidades de fraude.
Aunque a menudo se usan como sinónimos, conviene diferenciarlos:
Una API sin controles de consumo adecuados facilita múltiples escenarios de abuso:
No toda API necesita un único límite global. En general conviene pensar varias dimensiones:
La elección depende del modelo de amenaza y del tipo de cliente. Limitar solo por IP puede ser insuficiente si el actor distribuye tráfico; limitar solo por usuario puede no alcanzar si hay muchas cuentas falsas.
Un error común es aplicar el mismo límite a toda la API. Algunas operaciones son baratas y frecuentes; otras son críticas o costosas. Tratar todo igual puede ser ineficiente o incluso contraproducente.
Conviene distinguir:
Algunos límites protegen infraestructura, mientras que otros protegen lógica de negocio. Ambos son necesarios, pero no persiguen exactamente lo mismo.
| Tipo de límite | Ejemplo | Qué protege |
|---|---|---|
| Técnico | 100 requests por minuto | CPU, memoria, ancho de banda, base de datos |
| Funcional | 5 intentos de login por hora | Identidad y resistencia a fuerza bruta |
| De negocio | 1 canje por promoción y por usuario | Fraude y abuso de reglas comerciales |
| Operativo | 1 exportación pesada cada 15 minutos | Disponibilidad de procesos costosos |
Existen distintas formas de implementar límites: ventanas fijas, ventanas deslizantes, token bucket, leaky bucket y variantes híbridas. No hace falta entrar en detalle matemático para entender la idea principal: cada enfoque define cómo se cuenta el consumo y cómo se suavizan o endurecen los picos.
Lo importante desde seguridad es que la estrategia elegida:
Aplicar límites no es solo contar solicitudes. También hay que decidir cómo responde la API. Algunas opciones:
La reacción debe ser proporcional al riesgo y al tipo de operación. No todo exceso merece el mismo tratamiento.
Los flujos de autenticación requieren límites especialmente estrictos. Login, recuperación de cuenta, envío de OTP, refresh de tokens o validaciones sensibles suelen ser objetivos primarios de automatización.
Conviene controlar:
El scraping suele ser técnicamente legítimo en la forma, pero abusivo en volumen o propósito. Cuando una API expone datos estructurados, la extracción automatizada es mucho más sencilla que en una interfaz HTML tradicional.
Los controles útiles aquí incluyen:
No todas las solicitudes pesan igual. Algunas búsquedas, exportaciones, agregaciones o conversiones son mucho más costosas que una consulta simple. Si se las protege con el mismo límite genérico que al resto, el sistema puede seguir siendo vulnerable a abuso por costo computacional.
Una API madura identifica estas operaciones y les aplica políticas diferenciadas, incluso si el volumen total de requests parece bajo.
Elegir la clave de identidad correcta para limitar es crucial. Según el caso, conviene contar por:
Una sola dimensión rara vez alcanza. Un atacante puede distribuir tráfico entre IPs, crear múltiples cuentas o reutilizar varias credenciales. Por eso es habitual combinar señales.
En arquitecturas con múltiples nodos o regiones, aplicar límites de forma consistente se vuelve más complejo. Si cada instancia cuenta por separado sin coordinación, un atacante puede eludir parcialmente el control distribuyendo solicitudes entre nodos.
Esto obliga a pensar si los límites deben ser:
Los límites de volumen son útiles, pero no siempre bastan. También ayuda observar comportamiento:
La mejor defensa suele combinar límites con detección contextual.
En muchos casos conviene que el cliente legítimo entienda cuál es su margen de consumo. Esto puede ayudar a integraciones sanas, a backoff ordenado y a evitar reintentos ciegos.
Sin embargo, también hay que evitar exponer demasiado detalle que facilite ajuste fino por parte de atacantes. La información operativa compartida debe ser útil sin volverse una guía para el abuso.
Controlar el consumo de una API es una parte esencial de su seguridad porque el abuso no siempre se manifiesta como exploit clásico, sino como volumen, persistencia o costo desproporcionado. Rate limiting, cuotas y throttling permiten transformar una API ingenuamente expuesta en un servicio más resiliente, más justo para consumidores legítimos y mucho menos rentable para actores maliciosos.
En el próximo tema estudiaremos la gestión segura de tokens, expiración, refresh tokens y revocación, para analizar cómo gobernar el ciclo de vida de las credenciales modernas en APIs REST.