Las APIs REST son la columna vertebral de prácticamente cualquier servicio web moderno, y también el objetivo favorito de quienes buscan un ataque API fácil. Cada vez que una app móvil se conecta a un servidor, cada vez que un frontend pide datos a un backend, hay una API expuesta. Y donde hay exposición, hay riesgo. La seguridad de APIs se ha convertido en una disciplina propia porque las vulnerabilidades API REST no se comportan como los fallos web clásicos. El top 10 de OWASP API Security existe precisamente por esto: los vectores de api hacking requieren un enfoque diferente. Este artículo te va a explicar cuáles son esos vectores, cómo se explotan y qué puedes hacer para que tu API no acabe en un data breach.
OWASP API Security Top 10: la biblia del atacante (y del defensor)
OWASP publicó en 2023 la versión actualizada de su API Security Top 10 (OWASP API Security Top 10 2023). No es una lista teórica: refleja los patrones de ataque API más frecuentes en auditorías reales. Repasemos los que más daño hacen.
BOLA (Broken Object Level Authorization) — API1:2023
El rey indiscutible. Un atacante cambia un ID en la petición (GET /api/users/1234 → GET /api/users/1235) y accede a datos ajenos. Parece absurdo, pero según los informes de HackerOne, BOLA representa una proporción enorme de los reportes de vulnerabilidad API REST en programas de bug bounty. La raíz del problema: el servidor no verifica que el usuario autenticado tenga permiso para acceder al recurso solicitado.
Broken Authentication — API2:2023
Tokens JWT sin expiración, API keys hardcodeadas en repositorios públicos de GitHub, endpoints de login sin rate limiting. GitGuardian detectó en 2023 más de 12 millones de secretos expuestos en repositorios públicos. Muchos de ellos eran claves de API. Si tu autenticación es débil, da igual lo bien que protejas el resto: el atacante entra por la puerta principal.
Broken Object Property Level Authorization — API3:2023
Una variante sutil de BOLA. El usuario puede acceder al objeto, pero la API devuelve campos que no debería mostrar. Un GET /api/profile que devuelve el hash de la contraseña, el rol de admin o datos internos. También aplica al revés: un PATCH que permite modificar campos protegidos como {"role": "admin"}. Mass assignment, le llaman, y sigue siendo sorprendentemente común.
Vectores de ataque que explotan la lógica de negocio
Las vulnerabilidades más interesantes en api hacking no son las técnicas puras: son las que explotan la lógica de negocio a través de la API. Aquí la seguridad API se complica porque no hay un WAF que te salve.
Unrestricted Resource Consumption — API4:2023
¿Tu endpoint de búsqueda acepta ?limit=999999? ¿Puedes pedir un export de toda la base de datos sin paginación? Felicidades: tienes un vector de denegación de servicio incorporado. Un atacante puede también abusar de endpoints caros computacionalmente (generación de PDFs, envío de emails, procesamiento de imágenes) si no limitas las peticiones por usuario y por tiempo.
Unrestricted Access to Sensitive Business Flows — API5:2023
Esta es la que más cuesta entender. No es un fallo técnico: es un flujo de negocio que, automatizado vía API, causa daño. Bots que compran todo el stock de unas zapatillas. Scripts que crean miles de cuentas para abusar de ofertas de bienvenida. La API funciona "correctamente", pero el negocio pierde dinero. Protegerse requiere verificar cada interacción a nivel de flujo, no solo a nivel de endpoint.
SSRF (Server Side Request Forgery) — API7:2023
Si tu API acepta URLs como parámetro (para importar datos, generar previews, webhooks), un atacante puede hacer que tu servidor realice peticiones a recursos internos. El caso más célebre: la brecha de Capital One en 2019, donde un SSRF en una aplicación sobre AWS permitió acceder al servicio de metadatos de EC2 (169.254.169.254) y extraer credenciales IAM. Resultado: datos de más de 100 millones de clientes comprometidos. Esto conecta directamente con los ataques que explotan la infraestructura más allá del código.
Herramientas reales para auditar tus APIs
La teoría está bien, pero necesitas herramientas. Estas son las que usan los profesionales de OWASP API security en auditorías reales de seguridad de APIs REST.
| Herramienta | Uso principal | Licencia |
|---|---|---|
| Burp Suite | Interceptar y manipular peticiones API, fuzzing de parámetros | Community (gratis) / Pro |
| OWASP ZAP | Escaneo automatizado de APIs, integrable en CI/CD | Open source |
| Postman | Testing manual de endpoints, colecciones de pruebas de seguridad | Freemium |
| Nuclei (ProjectDiscovery) | Escaneo con templates de vulnerabilidades conocidas en APIs | Open source |
| Kiterunner | Descubrimiento de endpoints API ocultos (bruteforce inteligente) | Open source |
| jwt.io / jwt_tool | Análisis y manipulación de tokens JWT | Gratis / Open source |
Un flujo de auditoría básico: usa Kiterunner para descubrir endpoints no documentados, Burp Suite para interceptar y modificar peticiones (cambiar IDs, inyectar payloads, manipular tokens), y Nuclei para lanzar checks automatizados contra vulnerabilidades conocidas. Si trabajas con JWT, jwt_tool te permite probar ataques como "none algorithm", key confusion o token forgery.
Cómo proteger tu API: medidas concretas
Hablar de problemas sin ofrecer soluciones es de cobardes. Estas son las medidas que marcan la diferencia real contra un ataque a tu API REST.
- Autorización a nivel de objeto, siempre. Cada endpoint debe verificar que el usuario autenticado tiene permiso sobre el recurso específico que solicita. No basta con comprobar que el token es válido.
- Rate limiting granular. No un límite global: límites por usuario, por endpoint, por IP y por ventana temporal. Herramientas como Kong, Envoy o incluso un middleware en tu framework lo soportan.
- Validación estricta de entrada. Define un schema (OpenAPI/Swagger) y rechaza cualquier petición que no se ajuste. Cada campo con su tipo, longitud máxima y formato esperado. Un
iddebe ser UUID, no un string arbitrario. - Respuestas mínimas. Devuelve solo los campos que el cliente necesita. Un
GET /api/user/meno tiene que devolver el hash de la contraseña, la fecha de creación interna ni el tenant ID. - Logging y monitorización. Si no registras las peticiones a tu API, no sabrás que te están atacando hasta que sea tarde. Herramientas como Elastic SIEM, Datadog o incluso un stack ELK básico te dan visibilidad.
- Actualiza dependencias. La mayoría de frameworks tienen CVEs publicados que afectan directamente a la capa API. Mantener el software al día sigue siendo la medida más rentable.
Sobre JWT en particular: usa algoritmos asimétricos (RS256, ES256) en lugar de simétricos (HS256) cuando el token lo verifica un servicio diferente al que lo emite. Configura expiración corta (15 minutos para access tokens) y usa refresh tokens con rotación. Nunca almacenes JWT en localStorage; usa cookies HttpOnly con SameSite=Strict.
Casos reales que deberían quitarte el sueño
Para los escépticos que piensan que esto solo le pasa a los demás.
Optus (2022): La segunda telco de Australia expuso datos de aproximadamente 10 millones de clientes a través de una API sin autenticación. Literalmente, un endpoint público que devolvía datos personales incrementando un ID numérico. BOLA de manual. El atacante no necesitó ni un exploit: solo un bucle for.
Peloton (2021): Su API permitía consultar datos de cualquier usuario sin autenticación. Perfiles, edad, peso, ubicación, historial de entrenamientos. Un ataque API tan básico que avergüenza. El CVE no fue necesario porque no era un bug de software: era una decisión de diseño.
T-Mobile (2023): Una API expuesta permitió el acceso a datos de aproximadamente 37 millones de cuentas. El atacante estuvo accediendo durante semanas antes de que lo detectaran. Fallo de monitorización sumado a vulnerabilidad API REST en el control de acceso.
¿El patrón común? No son ataques sofisticados. No requieren zero-days ni exploits de memoria. Son fallos de diseño y configuración que un pentester junior encontraría en la primera hora. Si te preocupa que alguien entre en tus sistemas, pero dejas las APIs abiertas, es como poner una puerta blindada y dejar la ventana abierta. Algo parecido a lo que pasa con el ransomware de doble extorsión: el atacante entra por donde menos esperas.
Preguntas frecuentes
¿Qué diferencia hay entre seguridad web tradicional y seguridad de APIs?
La seguridad web tradicional se centra en proteger páginas y formularios HTML. La seguridad API protege endpoints que intercambian datos estructurados (JSON, XML). Las APIs exponen directamente la lógica de negocio y los datos, sin la capa visual del navegador que a veces actúa como filtro involuntario. Los ataques a APIs suelen ser más directos y automatizables.
¿Un WAF protege mi API REST contra estos ataques?
Parcialmente. Un WAF puede bloquear inyecciones SQL o XSS en parámetros de la API, y aplicar rate limiting básico. Pero no puede verificar la autorización a nivel de objeto (BOLA), ni detectar abusos de lógica de negocio, ni validar que tu JWT está bien implementado. Necesitas defensas en la propia aplicación.
¿Cómo puedo saber si mi API tiene vulnerabilidades OWASP?
Ejecuta un escaneo con OWASP ZAP o Nuclei contra tu API en un entorno de pruebas. Importa tu especificación OpenAPI/Swagger si la tienes. Para una auditoría más profunda, usa Burp Suite Pro con las extensiones de API testing o contrata un pentest profesional que incluya revisión de APIs.
¿GraphQL tiene los mismos problemas que REST?
Sí, y algunos adicionales. GraphQL permite consultas anidadas que pueden causar denegación de servicio (query depth attacks), introspección que revela todo el schema, y batching de mutaciones. OWASP también cubre GraphQL en sus guías. Las mismas categorías de vulnerabilidad aplican: autorización rota, autenticación débil y exposición excesiva de datos.
El siguiente paso
Abre tu navegador, accede a las herramientas de desarrollador (F12), y navega por tu aplicación mirando la pestaña Network. Filtra por peticiones XHR/Fetch. Observa cada endpoint que tu frontend llama: qué datos envía, qué recibe, qué headers usa. Ahora hazte una pregunta incómoda por cada petición: ¿qué pasa si cambio ese ID por otro? Si la respuesta te da datos de otro usuario, ya sabes por dónde empezar a parchear. Y si quieres profundizar en cómo los atacantes combinan técnicas para maximizar el impacto, explora los demás artículos del blog de MataSpam.
