OWASP API Top 10 (2026): Vulnerabilidades en APIs

En 2026, el 80 % de las empresas son "API-first" de facto. Tus apps móviles, tu frontend web, tus integraciones con SaaS de terceros… todo habla con APIs. Y los atacantes lo saben: según datos de la industria, los ataques dirigidos a APIs crecen más de un 30 % anual.

Lo curioso es que estos ataques no explotan vectores sofisticados y desconocidos. Casi siempre son los mismos errores de siempre. OWASP publicó en 2023 el API Security Top 10, que sigue siendo la referencia actual para entender qué falla en la seguridad de las APIs. A continuación te explico cada vulnerabilidad, con un ejemplo práctico y cómo detectarla en tus propias APIs.

API1: Broken Object Level Authorization (BOLA)

BOLA sigue siendo el número uno del Top 10 por un motivo claro: aparece en muchísimas APIs auditadas y suele ser fácil de explotar.

El problema es sencillo de entender. Tu API usa IDs en la URL o en el body para identificar recursos, pero no valida que el usuario que hace la petición tenga permiso para acceder a ese objeto concreto.

1# Petición legítima del usuario 123
2GET /api/users/123/orders HTTP/1.1
3Authorization: Bearer <token_user_123>
4
5# Ataque: mismo token, ID de otro usuario
6GET /api/users/456/orders HTTP/1.1
7Authorization: Bearer <token_user_123>
8# → 200 OK — ¡Acceso a pedidos del usuario 456!

El motivo por el que BOLA es tan prevalente es que los frameworks web facilitan crear rutas con parámetros dinámicos, pero no implementan comprobaciones de autorización por defecto. El desarrollador tiene que añadirlas manualmente para cada endpoint que acepte un ID. En una API con cientos de endpoints, es casi inevitable que alguno se escape.

Para detectarlo manualmente, crea dos usuarios, intercepta peticiones con herramientas como Burp o Postman, y prueba a intercambiar IDs entre sesiones. Si hay "cross-tenant", lo verás inmediatamente. De forma automatizada, necesitas herramientas que prueben cambios de ID de forma sistemática usando distintos tokens de autenticación, que es exactamente lo que hacen las soluciones de DAST orientadas a APIs.

API2: Broken Authentication

Las implementaciones de autenticación defectuosas siguen apareciendo con más frecuencia de la que pensaríamos. Hablamos de tokens sin fecha de expiración que viven indefinidamente, tokens que siguen funcionando después de hacer logout (porque el backend solo borra la cookie o el almacenamiento local, pero no invalida el token en el servidor), o endpoints de login sin ningún tipo de rate limiting que permiten fuerza bruta sin restricciones.

Un caso especialmente peligroso es el de JWTs sin exp claim o con tiempos de expiración de semanas o meses. Si un atacante consigue interceptar uno de esos tokens, tiene vía libre durante un período excesivo. Otro caso habitual es el de endpoints de login que responden de forma diferente según si el usuario existe o no, lo que permite a un atacante enumerar cuentas válidas antes de intentar la fuerza bruta.

API3: Broken Object Property Level Authorization (BOPLA)

Esta categoría engloba dos problemas que van de la mano y que combinados pueden ser devastadores. El primero es Excessive Data Exposure: el backend devuelve todo el objeto completo —incluyendo campos sensibles como password_hash, role, dni o internal_notes— y confía en que el frontend se encargará de ocultarlos. El problema es que cualquiera con DevTools o un proxy puede ver la respuesta completa del servidor, independientemente de lo que muestre la interfaz.

El segundo es Mass Assignment: el backend acepta y actualiza campos que el usuario no debería poder modificar.

La detección pasa por interceptar respuestas y buscar campos que no se muestran en la interfaz de usuario, y por probar a enviar campos "sensibles" en las peticiones de actualización. Si el servidor los acepta silenciosamente, tienes un BOPLA.

API4: Unrestricted Resource Consumption

Cuando una API no limita el consumo de recursos —CPU, memoria, ancho de banda, llamadas a servicios externos— las consecuencias van desde un DoS barato hasta disparar los costes de tu infraestructura cloud. También abre la puerta al abuso de funcionalidades caras como el envío de SMS, generación de PDFs o exportación masiva de datos. En un modelo serverless o de pago por uso, un atacante puede literalmente arruinarte enviando peticiones en bucle.

Los casos más frecuentes son endpoints sin paginación que devuelven cien mil registros de golpe, ausencia total de rate limiting (puedes enviar diez mil peticiones en segundos sin que nadie te frene), o uploads sin límite de tamaño que permiten subir ficheros de gigabytes. También entra aquí el abuso de endpoints de búsqueda con consultas intencionalmente complejas diseñadas para consumir CPU del servidor.

API5: Broken Function Level Authorization (BFLA)

Este problema aparece cuando funciones reservadas para administradores no tienen controles de acceso adecuados. Un usuario normal puede acceder a ellas simplemente adivinando o probando URLs, que a menudo siguen patrones predecibles.

Este tipo de vulnerabilidad es especialmente común en APIs donde los permisos se gestionan solo en el frontend, ocultando botones o menús pero sin validar nada en el servidor. La forma más directa de detectarlo es iniciar sesión como usuario normal y probar rutas que suenen a administración: /api/admin, /api/reports/export, /api/users/all, /api/config, /api/internal. También conviene revisar la documentación de la API (si existe un OpenAPI/Swagger accesible) en busca de endpoints que no deberían ser públicos.

API6: Unrestricted Access to Sensitive Business Flows

Aquí hablamos de flujos de negocio expuestos sin medidas contra el abuso automatizado masivo. Piensa en la compra de entradas limitadas, el registro en masa de cuentas, la generación ilimitada de likes o comentarios, la solicitud masiva de códigos por SMS, o la extracción automatizada de precios para inteligencia competitiva. Un bot que compra cien entradas en cinco segundos porque no hay límites por usuario es un ejemplo clásico que sigue ocurriendo en 2026.

Lo que distingue a API6 de API4 (Resource Consumption) es que aquí el problema no es el consumo de recursos del servidor, sino el abuso de la lógica de negocio. El servidor aguanta perfectamente, pero el negocio se ve perjudicado.

Para identificar este problema, empieza por listar las acciones críticas de tu aplicación: compras, altas de usuario, cambios de plan, solicitudes de descuento. Automatiza entre cincuenta y cien llamadas en poco tiempo. Si no hay frenos —ni rate limit, ni captcha, ni límites por cuenta, ni verificación adicional para acciones sensibles—, estás expuesto.

API7: Server-Side Request Forgery (SSRF)

SSRF ocurre cuando la API acepta URLs proporcionadas por el usuario y hace peticiones HTTP sin validar el destino. Un atacante puede aprovechar esto para escanear la red interna de tu infraestructura, acceder a los metadatos de AWS en 169.254.169.254 y robar credenciales IAM temporales, o alcanzar paneles de administración internos que no están expuestos públicamente. En entornos cloud, SSRF puede ser la puerta de entrada para comprometer toda la cuenta de AWS o GCP.

1# Endpoint legítimo: "Previsualizar URL"
2POST /api/preview
3{"url": "https://example.com/page"}
4
5# Ataque SSRF: acceder a metadatos de AWS
6POST /api/preview
7{"url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}
8
9# Respuesta del servidor (si vulnerable):
10{
11"AccessKeyId": "AKIAIOSFODNN7EXAMPLE",
12"SecretAccessKey": "wJalrXUtnFEMI/K7MDENG...",
13"Token": "FwoGZXIvYXdzEBYaDH..."
14}

API8: Security Misconfiguration

Las configuraciones inseguras por defecto o mal aplicadas siguen siendo un clásico que afecta a APIs de todo tipo y tamaño. Hablamos de CORS con * y credentials: true (que permite a cualquier dominio hacer peticiones autenticadas a tu API), stack traces completos visibles en producción que revelan rutas internas, versiones de dependencias y estructura del código, cabeceras de seguridad ausentes (HSTS, Content-Security-Policy, X-Content-Type-Options), o endpoints de debug y health-check desplegados sin ninguna protección.

En APIs modernas, un error de configuración especialmente peligroso es dejar los endpoints de Swagger/OpenAPI accesibles públicamente sin autenticación. Esto le da a un atacante un mapa completo de tu API, incluyendo endpoints que quizá no deberían ser públicos.

Para detectarlos, utiliza herramientas como OWASP ZAP, Burp Suite o comprobadores de cabeceras HTTP. Asegúrate de que no estás exponiendo errores verbosos ni rutas de depuración como /debug, /health, /metrics o /graphql/playground en producción sin autenticación.

API9: Improper Inventory Management

La falta de inventario de APIs y versiones es un problema más frecuente de lo que parece, especialmente en organizaciones que llevan años desarrollando y desplegando servicios. Versiones antiguas como /v1 que siguen expuestas y sin mantenimiento, endpoints de prueba olvidados como /debug, /test o /staging, y subdominios viejos con APIs obsoletas que nadie monitoriza.

El riesgo real es que estas APIs olvidadas suelen tener menos controles de seguridad que las versiones actuales y siguen conectadas a las mismas bases de datos de producción. Un atacante que encuentre una API /v1 sin rate limiting puede explotarla para acceder a los mismos datos que protege tu API /v3.

La solución empieza por generar un inventario completo de tus APIs —usando OpenAPI/Swagger, colecciones de Postman o herramientas de descubrimiento automatizado—. Haz discovery de subdominios y rutas. Y deshabilita las versiones de API que ya estén deprecadas: si no las necesitas, no deberían existir.

API10: Unsafe Consumption of APIs

Confiar ciegamente en los datos que devuelven APIs de terceros es un riesgo que muchos equipos pasan por alto. No validar las respuestas que recibes, reutilizar errores de servicios externos directamente en tus propias respuestas (lo que puede filtrar información interna), o no tratar las excepciones de integración como posibles fallos de seguridad son errores habituales.

Un ejemplo concreto: tu backend confía en la respuesta de un proveedor de identidad externo sin verificar la firma del token. Un atacante que comprometa ese proveedor —o que consiga inyectar una respuesta manipulada— podría suplantar a cualquier usuario de tu sistema. Otro caso habitual: consumes una API de scoring crediticio sin validar que los rangos y estados que devuelve tengan sentido, lo que podría permitir a alguien manipular los resultados.

La prevención pasa por tratar los datos de APIs externas con el mismo nivel de desconfianza que aplicas a los datos de tus usuarios. Valida esquemas, comprueba firmas, implementa timeouts agresivos y ten planes de contingencia para cuando el tercero falle o devuelva datos inesperados.

Cómo Encaja Vulnerabbit

En la práctica, lo que necesitas no es leer la lista del OWASP, sino saber cuáles de estas diez vulnerabilidades te afectan hoy en tus APIs.

Vulnerabbit escanea tus APIs contra el OWASP API Top 10 2023 y prioriza los hallazgos según su impacto real: datos expuestos, función de negocio afectada y criticidad del endpoint. No te da una lista genérica de problemas teóricos, sino ejemplos de explotación concretos y pasos de corrección adaptados a tu stack, ya sea Node, Django, Laravel, Spring Boot u otro. Y se integra directamente en tu CI/CD, para que cada despliegue pase por una verificación de seguridad sin que nadie tenga que acordarse de lanzar un escaneo manual.

El objetivo es que puedas centrar tu tiempo en arreglar cinco cosas importantes, no en revisar trescientos findings sin contexto.