OWASP API Security Top 10
En seguridad de APIs, el OWASP API Security Top 10 es una lista de concienciación aparte que cubre las vulnerabilidades que aparecen específicamente en las interfaces de programación. Existe porque las APIs fallan de otra manera que las páginas web: el grafo de objetos queda expuesto de forma directa, y la mayoría de sus entradas son problemas de autorización y no de inyección.
Cómo funciona
La lista la mantiene la misma fundación que la lista web general y es deliberadamente más estrecha. Sus primeras entradas tratan de la autorización a nivel de objeto individual y a nivel de función, y la lista continúa con las vulnerabilidades de autenticación, el consumo ilimitado de recursos, la asignación masiva de propiedades, la configuración de seguridad deficiente, el mal inventario de versiones y máquinas de la API, y el consumo inseguro de APIs de terceros.
Leer las dos listas una al lado de la otra enseña la diferencia de énfasis. En la lista web domina lo que un atacante puede inyectar. En la de API domina lo que a un atacante se le permite pedir, que es justo el desplazamiento que cabe esperar cuando el servidor deja de renderizar páginas y empieza a contestar preguntas directas sobre objetos.
Qué sale mal
El mal uso más frecuente es pasar un escáner web sobre una API e informar contra esta lista. Un escáner sin la especificación no conoce los identificadores de objeto, no puede construir un segundo tenant, y por tanto no puede detectar la autorización rota a nivel de objeto, que es la primera entrada y la que filtra los datos. Lo que sí encuentra son configuraciones erróneas y cabeceras ausentes, así que el informe parece completo y no cubre ninguna de las categorías que importan.
El segundo es el inventario. La lista incluye la mala gestión del inventario por un motivo que vemos en casi todos los encargos: la versión anterior de la API sigue desplegada, sin documentar, y solo aplica en parte las comprobaciones que se añadieron en la actual. Una shadow API no es un asunto abstracto de gobierno, es el endpoint que usamos.
Tercero, la asignación masiva se prueba sistemáticamente poco, porque hace falta que alguien intente enviar campos que la documentación no menciona, como un rol o un identificador de tenant, y compruebe si el modelo los enlaza.
Dónde aparece esto en una auditoría
Cogemos la especificación, generamos con ella el conjunto de peticiones y después probamos fuera de ella, porque las entradas sobre inventario y consumo solo aparecen cuando se abandona la superficie documentada. Los hallazgos se mapean a la lista para que el cliente pueda comparar años, y lo que no encaja en ninguna categoría se informa en sus propios términos. Conviene confirmar la edición vigente antes de citar números de entrada, porque se renumeran entre versiones. Esto forma parte de cómo se estructura una evaluación de API.