DAST en APIs: por qué tu escáner se queda en la página de login

Tu escáner dinámico corrió anoche y el informe salió limpio. Antes de tomarlo como buena noticia, hazte dos preguntas: ¿inició sesión? ¿Sabía que tus APIs existían?

En muchas organizaciones la respuesta honesta es no. El escáner recorrió las páginas públicas, llegó al formulario de login, no encontró nada más que seguir y se detuvo. Mientras tanto, la mayor parte de la lógica de negocio, y de los datos, vive detrás de endpoints de API autenticados a los que no apunta ningún enlace. Un informe limpio con esa configuración dice muy poco sobre la parte de la aplicación que más le interesa a un atacante.

Esta guía explica qué hace bien el DAST, por qué las APIs rompen la configuración clásica y cómo configurar las pruebas dinámicas para que un resultado limpio signifique algo.

Qué es DAST, y qué no es

Las pruebas dinámicas de seguridad de aplicaciones (DAST, por sus siglas en inglés) prueban una aplicación en ejecución desde afuera. La guía DevSecOps de OWASP las describe como pruebas de caja negra que encuentran vulnerabilidades y debilidades en una aplicación en vivo sin necesitar el código fuente. Son especialmente útiles para problemas de validación de entradas y salidas, fallos de autenticación y errores de configuración del servidor.

Por eso complementan a las técnicas estáticas, no las sustituyen. El SAST lee tu código, el SCA revisa tus dependencias, los escáneres de secretos e IaC revisan lo que subes al repositorio; el DAST comprueba cómo se comporta de verdad el sistema desplegado. Comparamos el lado estático en SAST, SCA, secretos e IaC.

El marco de desarrollo seguro del NIST (SSDF, SP 800-218) va en la misma línea. La práctica PW.8, "probar el código ejecutable para identificar vulnerabilidades", incluye entre sus ejemplos de implementación:

• Integrar pruebas dinámicas de vulnerabilidades en el conjunto de pruebas automatizadas del proyecto.
• Usar herramientas de fuzzing para encontrar problemas en el manejo de entradas.
• Si hay recursos, usar pruebas de penetración para simular cómo un atacante intentaría comprometer el software en escenarios de alto riesgo.

También pide registrar y clasificar cada hallazgo en el flujo de trabajo o en el gestor de incidencias del equipo de desarrollo. Un informe que nadie lee no cuenta como prueba.

Por qué las APIs rompen la configuración clásica de DAST

1. No hay enlaces que seguir

Un escáner web tradicional descubre páginas rastreando: sigue enlaces y envía formularios. Una API no tiene enlaces. Endpoints como la consulta de un cliente o la actualización de un pedido solo existen en el código del cliente y en la documentación.

Por eso el escaneo de APIs parte de una definición. La guía del proyecto ZAP para escanear APIs se basa en importar una definición OpenAPI o SOAP, para que el escáner sepa qué endpoints y parámetros probar. También recomienda darle valores de prueba realistas, porque las entradas por defecto pueden no recorrer suficiente código.

2. Todo lo interesante está detrás del login

Si el escáner nunca se autentica, solo prueba lo que puede alcanzar un visitante anónimo. La documentación de ZAP explica que la autenticación permite llegar al contenido que solo existe después de iniciar sesión, y que hay que indicarle a la herramienta cómo reconocer si sigue con la sesión abierta, con un indicador de sesión iniciada o cerrada. Sin esa comprobación, un escaneo puede perder la sesión a mitad de camino sin avisar y seguir reportando resultados de la página de login.

Para APIs con tokens, la guía de ZAP sugiere obtener el token con tu proceso habitual y añadirlo como encabezado en cada petición que envía el escáner.

3. Los peores fallos de las APIs son de autorización

Mira el OWASP API Security Top 10 (edición 2023). Tres de los diez riesgos tienen que ver con autorización:

• API1:2023 Broken Object Level Authorization (BOLA): un usuario cambia el ID de un objeto en la petición y obtiene el registro de otra persona.
• API3:2023 Broken Object Property Level Authorization: un usuario puede leer o cambiar campos de un objeto que no debería.
• API5:2023 Broken Function Level Authorization: un usuario normal puede llamar a una función de administrador.

OWASP califica BOLA como muy extendido y fácil de explotar, y explica que estos fallos suelen terminar en divulgación, modificación o destrucción no autorizada de datos. Su primera recomendación es un control de autorización en cada función que use datos del cliente para acceder a un registro, y recomienda de forma explícita escribir pruebas que evalúen el mecanismo de autorización.

Aquí está el problema: un escaneo que corre con un solo usuario no puede saber si el usuario A puede leer los datos del usuario B, porque solo ve un lado. La guía de pruebas de OWASP para referencias directas inseguras a objetos dice que la mejor forma de probarlas es con al menos dos usuarios, a menudo más, dueños de objetos distintos y con roles distintos, e intercambiar sus identificadores.

4. No puedes probar la API que no sabes que existe

API9:2023, Improper Inventory Management, cubre versiones viejas, hosts olvidados y endpoints sin documentar. OWASP recomienda inventariar cada host de API con su entorno, su audiencia (pública, interna o de socios) y su versión, generar la documentación automáticamente con estándares abiertos dentro del pipeline de CI/CD, y proteger todas las versiones expuestas, no solo la actual.

Para el DAST esto importa directamente. Si tu escaneo lee la especificación de la v2 mientras la v1 sigue en línea, el escáner nunca toca el endpoint con más probabilidades de no tener las últimas correcciones.

Una configuración práctica para que "limpio" signifique algo

1. Genera la definición de la API en el pipeline. Construye el documento OpenAPI a partir del código en CI, como recomienda OWASP API9, y dale ese mismo archivo al escáner. Una especificación mantenida a mano se desactualiza.
2. Escanea con sesión, en un entorno de pruebas. Usa cuentas de prueba dedicadas y configura un indicador de sesión iniciada para saber que la sesión se mantuvo. Los escaneos activos envían peticiones parecidas a un ataque, así que apúntalos a staging, no a datos de producción.
3. Usa al menos dos usuarios con roles distintos. Un usuario normal, otro con otros datos y un administrador. Es lo mínimo para probar BOLA y la autorización a nivel de función.
4. Ajusta las reglas para APIs. El perfil de escaneo de APIs de ZAP desactiva reglas pensadas para el navegador, como las de cross-site scripting, y añade comprobaciones de códigos de estado y tipos de contenido inesperados. Menos alertas irrelevantes significa que los desarrolladores leen el resto.
5. Ejecútalo de forma programada y en cada release. La guía DevSecOps de OWASP indica que el DAST puede correr como escaneo nocturno. Añade una ejecución antes de cada release importante.
6. Inventaría cada versión y cada host. Escanea lo que de verdad está expuesto, incluidas versiones viejas y endpoints de socios, no solo lo que aparece en la última especificación.
7. Deja a las personas las partes sensibles. La propia guía de ZAP advierte que un escaneo limpio no garantiza seguridad y sugiere una prueba de penetración manual para APIs sensibles. El NIST, en PW.8.2, dice lo mismo para escenarios de alto riesgo.
8. Lleva los hallazgos a donde se trabaja. Registra y clasifica los resultados en el gestor del equipo de desarrollo, como pide PW.8.2, y ordénalos junto con el resto de tu backlog de vulnerabilidades. Un fallo de autorización en una API de pagos expuesta a internet no es lo mismo que un encabezado faltante en una herramienta interna de pruebas; mira por qué la exposición a internet cambia la prioridad.

Preguntas frecuentes

¿El DAST reemplaza al SAST o a una prueba de penetración? No. El DAST ve el comportamiento en ejecución que las herramientas estáticas no ven, las herramientas estáticas ven rutas de código a las que un escáner nunca llega, y una persona con experiencia encuentra fallos de lógica de negocio que ninguno de los dos automatiza bien.

¿Puedo correr DAST contra producción? Las comprobaciones pasivas tienen poco riesgo, pero los escaneos activos envían entradas maliciosas que pueden crear o modificar datos. Corre los escaneos activos contra un entorno de staging que se parezca a producción y, si ahí tienes que usar datos de producción, protégelos como en producción, como aconseja OWASP API9.

Nuestro escáner soporta GraphQL. ¿Cambia algo? Los principios son los mismos: dale el esquema a la herramienta, haz que se autentique y prueba la autorización con más de un usuario.

¿Cómo decidimos qué hallazgos de DAST corregir primero? Igual que con cualquier otro hallazgo: explotabilidad, exposición e impacto en el negocio, no solo la etiqueta del escáner. Lo explicamos en cómo priorizar vulnerabilidades.

Cómo ayuda priorIQ.ai

CodeIQ cubre el lado estático de la seguridad de aplicaciones: SAST, SCA, IaC y escaneo de secretos, con triage por IA y correcciones verificadas que se abren como pull request. Los hallazgos de tus herramientas de pruebas dinámicas se suman a esos: PriorIQ Core se conecta a tus escáneres, deduplica sus resultados con los de CodeIQ y tus otros módulos, y ordena todo por riesgo real, para que el fallo de autorización en una API expuesta no se pierda debajo de mil alertas de poco valor. Solicita una demo.