Tema 4
Las APIs no suelen ser atacadas solo con técnicas tradicionales de explotación. Muchas veces el riesgo principal aparece cuando un atacante usa la API exactamente como fue diseñada, pero a escala, con persistencia, con objetivos de fraude o con la intención de extraer información y forzar la lógica del sistema.
Las APIs REST están pensadas para ser consumidas por software. Esa misma característica que las vuelve útiles también las hace ideales para el abuso automatizado. Un atacante no necesita interactuar con pantallas, ni imitar un flujo visual, ni depender del navegador si puede hablar directamente con el backend.
Por eso, muchas amenazas en APIs no se parecen a la imagen clásica de “romper” una aplicación. En cambio, consisten en descubrir recursos, probar combinaciones de parámetros, iterar identificadores, repetir solicitudes a gran velocidad o encadenar llamadas legítimas con una intención maliciosa.
Entender estas amenazas es clave para diseñar controles realistas. Una API puede tener autenticación correcta y seguir siendo vulnerable a abuso, scraping, exfiltración, enumeración o automatización fraudulenta.
Una amenaza es una forma plausible en la que una capacidad expuesta por la API puede ser utilizada de manera indebida para afectar confidencialidad, integridad, disponibilidad o negocio. No todas las amenazas requieren una vulnerabilidad técnica tradicional. Muchas se apoyan en exposición legítima pero insuficientemente controlada.
En APIs es útil pensar las amenazas en varias categorías:
Antes de abusar de una API, un atacante suele intentar entenderla. Esa etapa de reconocimiento puede incluir inspección de documentación pública, revisión de tráfico capturado desde una app legítima, prueba de endpoints comunes, análisis de errores y exploración de versiones antiguas o subdominios relacionados.
Este reconocimiento puede revelar:
La enumeración ocurre cuando un atacante prueba sistemáticamente identificadores, nombres de usuario, correos, claves de negocio u otros valores para descubrir qué recursos existen y cuáles responden de manera diferente.
Esto puede darse de muchas formas:
La enumeración suele ser silenciosa y de bajo volumen al principio. Su valor para el atacante está en construir conocimiento explotable: qué usuarios existen, qué pedidos están activos, qué documentos son accesibles, qué tenants están presentes, qué rutas viven detrás del gateway.
A veces se subestima la enumeración porque no implica daño visible inmediato. Sin embargo, es una amenaza estratégica: transforma una API “opaca” en una API predecible para el atacante.
| Dato enumerado | Cómo se obtiene | Qué habilita después |
|---|---|---|
| Usuarios válidos | Login, recuperación o invitaciones | Password spraying, phishing, takeover |
| IDs de objetos | Iteración en rutas o filtros | BOLA, scraping, acceso indebido |
| Tenants o clientes | Subdominios o referencias organizativas | Targeting específico y pivoting |
| Endpoints activos | Pruebas de rutas y errores | Reconocimiento avanzado y abuso funcional |
| Estados de negocio | Consultas repetidas sobre recursos | Fraude, arbitraje, inteligencia competitiva |
El abuso funcional ocurre cuando el atacante usa una funcionalidad legítima para un fin no previsto o a una escala que el sistema no estaba preparado para soportar. No siempre hay exploit técnico: la amenaza aparece por falta de límites, controles contextuales o validación del comportamiento esperado.
Ejemplos comunes:
La automatización maliciosa es el uso de scripts, bots, headless clients o infraestructura distribuida para ejecutar grandes volúmenes de solicitudes con objetivos de descubrimiento, fraude, scraping o degradación. Las APIs son especialmente atractivas para esto porque ofrecen un contrato estable y fácil de automatizar.
Algunos objetivos típicos son:
La exfiltración consiste en extraer información de forma no autorizada o excesiva. En APIs puede ocurrir por una vulnerabilidad clara, como una autorización rota, o por una combinación de respuestas válidas, filtros permisivos y ausencia de límites de consumo.
La exfiltración no siempre aparece como un “dump” masivo de una sola vez. Muchas veces se produce lentamente, en pequeños lotes, mezclada con tráfico normal, para evitar detección.
Vectores comunes:
El scraping en APIs es particularmente eficiente porque los datos ya están estructurados. No hay que parsear HTML complejo ni emular el navegador si el backend entrega JSON limpio y estable.
Esto puede afectar:
El scraping puede provenir de actores externos, competidores, agregadores no autorizados o incluso clientes legítimos que sobreutilizan su acceso.
Cuando la API expone login, refresh, recuperación de cuenta o validación de credenciales, se convierte en un blanco natural para ataques automatizados. El credential stuffing reutiliza combinaciones de usuario y contraseña obtenidas de otras brechas; el password spraying intenta pocas contraseñas comunes contra muchos usuarios para evitar bloqueos.
Estas amenazas se potencian cuando existen:
Un replay ocurre cuando una solicitud legítima es capturada o reproducida para obtener nuevamente un efecto. Esto puede ser grave en operaciones de pago, activación, confirmación, canje o cualquier acción no idempotente.
Incluso sin interceptar tráfico, algunos atacantes simplemente repiten solicitudes exitosas observadas desde el cliente legítimo. Si la API no tiene protección contextual, puede ejecutar la misma operación múltiples veces.
Los replays suelen relacionarse con:
No toda fuerza bruta se dirige a contraseñas. En APIs también puede orientarse a códigos OTP, tokens de invitación, identificadores de descuento, números de orden, referencias de documentos, claves de reseteo o combinaciones de filtros.
El atacante aprovecha que una API es programable para probar miles de combinaciones con poca fricción. Si la validación es débil y no existen límites contextuales, la fuerza bruta se vuelve muy rentable.
No toda denegación de servicio necesita saturar la red. En APIs, a veces basta con explotar endpoints costosos: búsquedas complejas, exportaciones, generación de reportes, agregaciones pesadas o consultas con filtros que impactan base de datos.
Un atacante puede degradar la API:
En sistemas multi-tenant, una amenaza especialmente crítica es mezclar contextos entre clientes, organizaciones o espacios aislados. A veces el error no es una falla técnica compleja, sino un filtro mal aplicado o una referencia de tenant confiada al cliente.
Esto puede derivar en:
Las amenazas en APIs suelen dejar patrones observables si existe suficiente monitoreo. Algunas señales típicas son:
Muchas organizaciones detectan bien fallos del servidor, pero no abuso de la lógica. El problema es que gran parte de estas amenazas se manifiesta como tráfico “válido” desde el punto de vista técnico.
Pasan desapercibidas cuando:
Las APIs REST enfrentan amenazas que combinan técnica, automatización y abuso de lógica. Un atacante puede descubrir, iterar, extraer y forzar el sistema utilizando las mismas capacidades que usan los clientes legítimos. Por eso, asegurar una API requiere pensar no solo en acceso, sino también en comportamiento esperado, límites, contexto y señales tempranas de abuso.
En el próximo tema estudiaremos OWASP API Security Top 10 para ordenar estas amenazas dentro de un marco de referencia ampliamente utilizado en seguridad de APIs.