OWASP API Security Top 10: los 10 riesgos y cómo detectarlos
Si diriges la seguridad de una empresa tecnológica, es muy probable que el grueso de tu superficie de exposición ya no esté en la web tradicional, sino en las APIs. Aplicaciones móviles, integraciones B2B, microservicios internos, webhooks de terceros: todo se apoya en endpoints que hablan JSON. El problema es que la mayoría de programas de seguridad siguen midiendo la web con criterios pensados para el navegador, y las APIs tienen una lógica de ataque distinta.
El OWASP API Security Top 10 existe precisamente porque los fallos que comprometen una API no son los mismos que comprometen una web clásica. No hablamos tanto de XSS o de inyecciones visibles, sino de fallos de autorización a nivel de objeto y de función que un escáner automático rara vez detecta. Este artículo desglosa los diez riesgos de la edición 2023, con foco en los dos que más impacto real generan —BOLA y BFLA— y explica qué debe hacer un pentesting de API para encontrarlos.
Qué es el OWASP API Security Top 10
Es un documento de referencia mantenido por la OWASP Foundation que clasifica las diez categorías de riesgo más críticas y frecuentes en interfaces de programación. La edición vigente (2023) reordenó y afinó la de 2019 a partir de incidentes reales y consultas a la comunidad. No es un estándar de cumplimiento obligatorio, pero sí el marco de facto para evaluar la seguridad de APIs y una base excelente para definir el alcance de una auditoría.
Su valor para un CISO es doble: da un lenguaje común con el equipo de desarrollo y permite priorizar. No todos los riesgos pesan lo mismo, y los dos primeros de la lista concentran una parte desproporcionada de las brechas.
Los 10 riesgos, en lenguaje accionable
API1:2023 — BOLA (Broken Object Level Authorization)
Es el riesgo número uno, y con razón. BOLA ocurre cuando la API valida que estás autenticado, pero no verifica que el objeto concreto que pides te pertenece. El caso de manual: una petición a GET /api/v1/invoices/1043 que devuelve la factura de otro cliente con solo cambiar el identificador. El endpoint funciona, la sesión es válida, y aun así estás filtrando datos ajenos.
Lo peligroso de BOLA es que es invisible para las pruebas convencionales: la respuesta es un 200 legítimo. Solo se detecta razonando sobre la lógica de negocio y probando el acceso cruzado entre usuarios con distintos privilegios. Afecta a cualquier endpoint que reciba un identificador de recurso, que en una API moderna son prácticamente todos.
API2:2023 — Broken Authentication
Fallos en el mecanismo de autenticación: tokens JWT mal validados (firma no verificada, algoritmo none aceptado), ausencia de rate limiting en el login que habilita fuerza bruta, tokens que no caducan o refresh tokens sin revocación. Compromete la identidad de forma directa.
API3:2023 — BOPLA (Broken Object Property Level Authorization)
Fusiona los antiguos excessive data exposure y mass assignment. Por un lado, la API devuelve más propiedades de las que el consumidor debería ver (filtrado en el cliente en lugar del servidor). Por otro, acepta que el usuario escriba propiedades que no debería, como enviar "role": "admin" en un PATCH de perfil y que el backend lo asigne sin control.
API4:2023 — Unrestricted Resource Consumption
Ausencia de límites en recursos: peticiones sin paginación que devuelven millones de registros, ausencia de límites de tamaño en cargas, o consultas GraphQL anidadas que agotan la CPU. Deriva en denegación de servicio y en costes de infraestructura descontrolados.
API5:2023 — BFLA (Broken Function Level Authorization)
El segundo protagonista de este artículo. Mientras BOLA es acceso a objetos ajenos, BFLA es acceso a funciones que no te corresponden por rol. Un usuario estándar que invoca DELETE /api/v1/users/55 o POST /api/v1/admin/config y la API lo ejecuta porque solo la interfaz —no el backend— restringía esa acción a administradores.
BFLA suele explotarse descubriendo endpoints administrativos no documentados o cambiando el método HTTP (de GET a PUT) sobre una ruta conocida. Igual que BOLA, requiere comparar el comportamiento con distintos niveles de privilegio; ningún escáner de firmas lo resuelve.
API6:2023 — Unrestricted Access to Sensitive Business Flows
Abuso de flujos legítimos de negocio sin salvaguardas: automatizar la compra de todo el stock, la creación masiva de cuentas o el envío de comentarios. La API funciona como debe, pero el diseño no contempla el abuso a escala.
API7:2023 — Server Side Request Forgery (SSRF)
La API acepta una URL proporcionada por el usuario y realiza una petición sin validarla, permitiendo alcanzar servicios internos o metadatos de la nube (por ejemplo, endpoints de credenciales en entornos cloud).
API8:2023 — Security Misconfiguration
Cabeceras de seguridad ausentes, CORS permisivo, mensajes de error verbosos, TLS mal configurado o servicios de depuración expuestos en producción.
API9:2023 — Improper Inventory Management
Endpoints antiguos (/v1 conviviendo con /v3), entornos de staging accesibles o documentación desactualizada. Las shadow APIs y las zombie APIs son puerta de entrada frecuente porque nadie las mantiene ni las monitoriza.
API10:2023 — Unsafe Consumption of APIs
Confiar ciegamente en datos de APIs de terceros e integrarlos sin validación, propagando así vulnerabilidades desde proveedores hacia tu propio sistema.
Por qué los escáneres automáticos no bastan
Los fallos de autorización —BOLA, BFLA y BOPLA— comparten una característica: dependen del contexto y de la lógica de negocio, no de patrones sintácticos. Un DAST no sabe que la factura 1043 pertenece a otro cliente ni que el endpoint de borrado debería estar restringido a administradores. Para detectarlos hace falta modelar los roles, generar credenciales de varios usuarios y probar sistemáticamente el acceso cruzado.
Un pentesting de API riguroso aborda esto de forma manual y estructurada:
- Reconocimiento e inventario: se enumeran endpoints reales a partir de la especificación OpenAPI/Swagger, tráfico capturado y descubrimiento activo, atacando también el riesgo API9.
- Matriz de autorización: se cruzan roles y recursos para probar BOLA y BFLA de forma exhaustiva, usuario contra usuario y rol contra rol.
- Análisis de propiedades: se inspeccionan las respuestas para detectar exposición de datos y se prueba mass assignment inyectando propiedades no previstas.
- Abuso de flujos y límites: se validan rate limiting, paginación y protecciones frente a automatización.
En CISEC seguimos metodologías como OWASP (API Security Top 10 y ASVS), PTES y MITRE ATT&CK, con un equipo certificado OSCP acostumbrado a razonar sobre lógica de negocio, no solo a lanzar herramientas. Nuestra plataforma de pentesting continuo AISAC permite además reevaluar los endpoints tras cada despliegue, algo especialmente relevante en APIs que cambian con cada sprint.
Relación con el cumplimiento
Aunque el OWASP API Security Top 10 no es en sí una norma, encaja de forma natural en los requisitos de auditoría de ENS, ISO 27001 (control de acceso y gestión de vulnerabilidades) y en las exigencias de proveedores en contratos B2B. Para una empresa que factura a través de integraciones, demostrar que sus APIs se auditan contra este marco es cada vez más un requisito comercial, no solo de seguridad. Documentar los hallazgos y su remediación aporta evidencia directa para estos procesos.
Preguntas frecuentes
¿Cuánto dura un pentesting de API?
Depende del número de endpoints, de la complejidad de los roles y de si hay lógica de negocio crítica. Un alcance típico de una API media suele requerir entre una y tres semanas de trabajo efectivo. Lo que marca la diferencia no es el número de endpoints, sino la cantidad de combinaciones rol-objeto que hay que verificar para descartar BOLA y BFLA.
¿Necesito darle credenciales al equipo de pentesting?
Sí, y de varios roles distintos. La detección de fallos de autorización exige comparar el comportamiento entre usuarios con diferentes privilegios. Un test sin credenciales (black box puro) deja fuera precisamente los dos riesgos más críticos de la lista.
¿Un escáner automático cubre el OWASP API Security Top 10?
Parcialmente. Detecta bien misconfiguraciones (API8) y algunos problemas de autenticación, pero es ciego ante BOLA, BFLA y el abuso de flujos de negocio, que requieren análisis manual experto. Por eso la combinación de automatización para cobertura y pruebas manuales para lógica es la aproximación correcta.