¿Qué son los ataques a APIs?

¿Qué son los ataques a APIs?

Los ataques a APIs son intentos de abusar de una interfaz de programación para leer datos que el llamante no debería ver, modificar datos que no debería tocar o agotar el servicio para que los usuarios reales no puedan usarlo. Apuntan directamente a los endpoints que hay detrás de las apps web y móviles, así que un fallo que el front end oculta sigue siendo alcanzable con una simple petición HTTP. Entenderlos es el primer paso de la seguridad de APIs. Esta página es contexto defensivo.

Por qué los atacantes van a por las APIs

• Acceso directo a los datos: las respuestas son estructuradas y suelen venir directamente de la base de datos.
• Forma predecible: rutas documentadas e identificadores secuenciales son fáciles de automatizar.
• Muchos puntos de entrada: las APIs públicas, de socios e internas multiplican la superficie, y las olvidadas siguen vivas (ver descubrimiento de APIs).
• Sin navegador de por medio: los bots llaman a los endpoints sin CAPTCHA ni páginas visibles.

OWASP API Security Top 10 (2023)

La referencia estándar es el OWASP API Security Top 10, edición 2023. Sus diez riesgos (con el nombre original) y la idea defensiva de cada uno:

Para un repaso en lenguaje llano de los principales, consulta principales riesgos de seguridad de APIs.

Un ejemplo concreto

Tomemos BOLA (API1). Un usuario autenticado abre /api/orders/1001 y ve su propio pedido. Si el servidor solo comprueba que el usuario ha iniciado sesión, cambiar el número a 1002 puede devolver el pedido de otra persona. Un script puede probar miles de IDs en minutos. La solución no es ocultar los IDs, sino comprobar en cada petición que este llamante es el dueño de este pedido.

Errores comunes al defender APIs

• Confiar en el front end. Ocultar un botón no protege el endpoint que hay detrás.
• Autenticación sin autorización. Saber quién es alguien no decide qué puede tocar.
• Limitar la tasa como único control. Frena el abuso (abuso de APIs), pero no sirve contra BOLA ni inyección.
• Versiones olvidadas. Un /v1 antiguo sin las nuevas comprobaciones es una puerta habitual.
• Confiar en APIs de socios. Trata sus respuestas como entrada no confiable.

Cómo detectar y reducir los ataques

Combina controles en capas: autentica y autoriza cada petición a nivel de objeto y de función, valida la entrada con un esquema, devuelve solo los campos necesarios, limita tasas y tamaños por cliente, mantén un inventario de endpoints y versiones y registra lo suficiente para investigar. Conviene alertar ante ráfagas de respuestas 401 y 403, un cliente que recorre IDs secuenciales y picos repentinos de errores o latencia. Para inundaciones, consulta cómo detener ataques DDoS y la guía de límites de tasa en APIs.

Dónde encajan la monitorización y las pruebas de carga

LoadFocus no es un escáner de seguridad y no encuentra vulnerabilidades como inyección o BOLA. Ayuda en la parte de disponibilidad. La monitorización de APIs comprueba endpoints de forma programada (las comprobaciones gratuitas se ejecutan cada 5 minutos) y avisa cuando cambian los códigos de estado, las respuestas o los tiempos de respuesta, lo que puede ser una señal temprana de que algo está golpeando la API. Las pruebas de carga muestran cómo se comporta tu propia API con mucho tráfico concurrente, para confirmar que los límites de tasa actúan y que el servicio se degrada con orden. Prueba solo sistemas propios o con permiso.

Preguntas frecuentes: ataques a APIs

¿Cuál es el ataque a APIs más común?

OWASP sitúa Broken Object Level Authorization como API1:2023, el primer riesgo de su Top 10, y es muy frecuente porque aparece siempre que un endpoint confía en un ID sin comprobar la propiedad.

¿En qué se diferencian de los ataques a aplicaciones web?

Apuntan a endpoints entre máquinas que devuelven datos estructurados, sin página ni CAPTCHA de por medio. Eso hace más fácil encontrar y automatizar fallos de autorización y de entrada.

¿Pueden detenerlos un WAF o un limitador de tasa?

Ayudan con inundaciones, cargas conocidas y fuerza bruta, pero no con fallos de lógica como BOLA o el abuso de flujos de negocio. Funcionan mejor junto a comprobaciones de autorización y validación de entrada.

¿Cómo sé si mi API está bajo ataque?

Compara con una línea base: tráfico repentino de clientes concretos, más respuestas 401 o 403, recorrido de IDs secuenciales y picos de latencia. La monitorización continua con alertas lo hace visible rápido.

¿Una prueba de carga encuentra fallos de seguridad?

No. Mide rendimiento y estabilidad con tráfico. Puede confirmar que los límites de tasa y la capacidad aguantan, pero para encontrar vulnerabilidades hace falta una revisión de seguridad o un escáner.