Tema 5
Asegurar una API requiere una forma ordenada de pensar los riesgos. El OWASP API Security Top 10 ofrece un marco práctico para identificar las fallas más frecuentes y peligrosas en APIs modernas, con foco en autorización, exposición de datos, abuso y errores de diseño que aparecen una y otra vez en sistemas reales.
Las vulnerabilidades en APIs no aparecen de forma aleatoria. Muchas responden a patrones repetidos: falta de autorización por objeto, autenticación débil, exposición excesiva de datos, consumo sin límites o errores en la configuración operativa. El valor de OWASP API Security Top 10 está en organizar esos patrones en un lenguaje común.
Ese lenguaje común sirve para varias cosas: revisar diseño, orientar pruebas, priorizar remediaciones, explicar riesgos al equipo y evitar que la seguridad dependa únicamente de intuición o memoria individual.
OWASP no reemplaza el análisis del negocio ni del contexto, pero sí ofrece una base sólida para pensar qué suele salir mal en APIs y por qué.
OWASP API Security Top 10 es una lista curada de las categorías de riesgo más relevantes para APIs modernas. No es un checklist completo de todo lo que podría fallar, sino una priorización de los problemas que aparecen con mayor frecuencia o mayor impacto en entornos reales.
Su foco está en APIs, no en aplicaciones web genéricas. Por eso enfatiza fallas de autorización a nivel de objeto y función, exposición de datos, gestión de inventario, consumo de recursos y abuso de negocio, aspectos que en APIs suelen tener más peso que vulnerabilidades web tradicionales.
Usar OWASP API Top 10 aporta estructura. En lugar de hablar de “la API tiene problemas de seguridad” de forma difusa, permite decir con precisión si el riesgo está en autorización, inventario, consumo, autenticación, exposición de datos o acceso a funciones sensibles.
En la práctica, este marco sirve para:
Aunque cada edición puede refinar nombres y énfasis, las categorías de OWASP API Top 10 suelen agruparse alrededor de estos grandes temas:
El orden exacto importa menos que la comprensión profunda de qué tipo de falla representa cada categoría.
Esta categoría aparece cuando la API no valida correctamente si el usuario autenticado puede acceder a un objeto específico. Es una de las fallas más peligrosas porque permite leer o modificar recursos de otros usuarios simplemente cambiando un identificador.
Ejemplos típicos:
La causa raíz no suele ser el formato del identificador, sino la falta de verificación de ownership o permiso por objeto.
La autenticación rota agrupa problemas que permiten suplantar identidades, robar sesiones o abusar del proceso de login. No se limita a contraseñas débiles; también incluye tokens mal diseñados, sesiones mal gestionadas, ausencia de MFA y flujos de recuperación inseguros.
Se manifiesta cuando:
Esta categoría apunta a la autorización por propiedad o atributo. Incluso si el usuario accede legítimamente al objeto correcto, puede ocurrir que vea o modifique campos que no debería controlar.
Ejemplos clásicos:
Esta categoría cubre el uso no controlado de recursos computacionales, operativos o funcionales. No se trata solo de rate limiting; también incluye consultas costosas, exportaciones pesadas, archivos demasiado grandes, paginaciones excesivas o procesos que consumen CPU, memoria o ancho de banda sin límites razonables.
El impacto puede ser:
Aquí el problema no está en el objeto, sino en la función. Un usuario autenticado logra ejecutar operaciones reservadas para otro rol o contexto porque la API no verifica bien la autorización a nivel de endpoint o acción.
Ejemplos:
Esta categoría suele aparecer en APIs con roles complejos, crecimiento rápido o endpoints heredados que nadie revisó.
Este riesgo aparece cuando un flujo de negocio sensible puede automatizarse o explotarse sin controles adicionales. No siempre hay una vulnerabilidad técnica tradicional; muchas veces el problema es que una operación económicamente o funcionalmente sensible no tiene defensas proporcionales.
Casos típicos:
Esta categoría conecta directamente seguridad con fraude y abuso de negocio.
La SSRF ocurre cuando la API permite que el servidor realice solicitudes hacia destinos controlados o influidos por el atacante. Esto puede transformar la API en un pivote para alcanzar servicios internos, metadatos de nube, paneles administrativos o recursos de red no expuestos directamente.
Ejemplos de vectores:
Las configuraciones inseguras abarcan un campo muy amplio: CORS abierto, debug habilitado, cabeceras mal definidas, entornos expuestos, secretos visibles, respuestas verbosas, métodos HTTP innecesarios, gateways mal configurados o defaults inseguros en frameworks.
Esta categoría es importante porque muchas brechas no surgen de código complejo, sino de configuraciones débiles o incoherentes entre entornos.
| Configuración insegura | Ejemplo | Impacto posible |
|---|---|---|
| CORS permisivo | `Access-Control-Allow-Origin: *` con credenciales | Exposición a clientes web no previstos |
| Debug expuesto | Mensajes con stack traces o rutas internas | Fuga de información técnica |
| Métodos innecesarios habilitados | `PUT`, `DELETE` o `OPTIONS` sin necesidad real | Superficie de ataque ampliada |
| Secretos en configuración | Claves en repositorio o archivos públicos | Compromiso de terceros y escalación |
Una API no puede protegerse bien si no se sabe exactamente qué existe. Esta categoría trata el inventario deficiente de endpoints, versiones, ambientes, consumidores, subdominios y rutas legacy.
El riesgo aparece cuando sobreviven interfaces olvidadas, versiones antiguas con controles débiles o endpoints experimentales que nadie monitorea.
Ejemplos comunes:
Las APIs no solo exponen servicios; también consumen servicios de terceros. Esta categoría recuerda que una API puede heredar riesgo al confiar demasiado en integraciones externas, SDKs, callbacks o respuestas de otros sistemas.
Problemas típicos:
Clasificar bien no es poner etiquetas al azar. Requiere entender cuál es la causa raíz del hallazgo. Por ejemplo, si un usuario puede leer el pedido de otro cambiando el ID, el núcleo del problema es BOLA, aunque también haya exposición de datos. Si un endpoint administrativo está abierto a usuarios normales, el corazón del problema es BFLA.
Una buena clasificación ayuda a remediar bien. Una mala clasificación puede llevar a controles superficiales que no corrigen la raíz del riesgo.
En seguridad de APIs, un mismo incidente puede mostrar varios síntomas. Por ejemplo, una exportación masiva de datos puede ser consecuencia de BOLA, de consumo sin límites o de una mala política de alcance. Si solo se mira el efecto visible, la remediación puede quedar incompleta.
Preguntas útiles para llegar a la causa raíz:
OWASP API Top 10 es especialmente útil antes del desarrollo o durante revisiones de arquitectura. Permite recorrer sistemáticamente preguntas como estas:
OWASP API Security Top 10 es un marco extremadamente valioso para ordenar el pensamiento sobre seguridad en APIs REST. Permite reconocer patrones repetidos, priorizar controles y evitar que los equipos traten cada hallazgo como un caso aislado. Su mayor fortaleza no está en memorizar una lista, sino en ayudar a identificar familias de fallas antes de que se conviertan en incidentes reales.
En el próximo tema estudiaremos la autenticación en APIs, comenzando por enfoques como API Keys, Basic Auth, tokens y sesiones, para analizar qué resuelve cada uno y qué riesgos introduce.