DAST funciona en caja negra. Es lo que mejor refleja la superficie de ataque visible desde fuera, pero no ve la lógica interna ni rutas no alcanzables desde el cliente. Por eso se combina con SAST y con pentesting: cada técnica mira un ángulo distinto.
Qué es DAST
DAST (Dynamic Application Security Testing) es el análisis de seguridad de una aplicación en ejecución, observada desde fuera y sin acceso al código. La herramienta arranca como un usuario más, recorre la aplicación, identifica formularios, endpoints y APIs, y prueba contra ellos cargas que disparan vulnerabilidades habituales: inyecciones SQL y de comandos, XSS reflejado y persistente, errores de autenticación y autorización, exposición de datos sensibles, configuración por defecto o gestión incorrecta de sesiones. El conjunto de pruebas se apoya en marcos como OWASP Top 10 y OWASP ASVS. A diferencia de SAST, que necesita el código, DAST funciona como una caja negra y ve lo que ve un atacante: configuración real, autenticación efectiva y comportamiento del runtime.
Por qué importa
Para un responsable de seguridad con aplicaciones expuestas a internet, lo que de verdad importa es la exposición real del servicio en producción, no la teórica del código. DAST aporta esa visión: descubre lo que solo aparece cuando la aplicación está montada (cabeceras de seguridad mal configuradas, cookies sin atributos seguros, redirecciones abiertas, tokens que sobreviven al logout, errores que filtran trazas) y permite además repetir la prueba cada vez que se promueve un cambio. Es una pieza natural en el ciclo de CI/CD contra el entorno de staging y un primer filtro útil antes de gastar capacidad de pentest manual. La trampa habitual está en cubrir solo lo que el spider descubre por sí mismo y dejar fuera las APIs autenticadas, que son donde vive la mayor parte de la lógica de negocio y de las vulnerabilidades de impacto.
Puntos clave
Para que rinda hay que darle credenciales y rutas. Sin sesión autenticada, el escáner solo recorre la zona pública y deja sin probar el ochenta por ciento de la aplicación. Configurar autenticación robusta (incluida MFA simulada cuando aplica) y un mapa de rutas o spec OpenAPI multiplica la cobertura.
Las APIs necesitan tratamiento aparte. Spiderear una API REST no funciona; el escáner necesita el esquema (OpenAPI, GraphQL introspection o postman collection) para generar peticiones válidas. Sin spec, DAST cubre formularios HTML y deja sin tocar la parte donde vive la lógica de negocio.
El falso negativo es más caro que el falso positivo. Una vulnerabilidad de inyección o autenticación que DAST no detecta sigue ahí cuando llega el pentest o el atacante. Conviene calibrar la herramienta con un conjunto pequeño de vulnerabilidades intencionadas en staging y medir qué porcentaje atrapa antes de confiar en ella.
DAST no sustituye al pentesting manual. Los fallos de lógica de negocio, los abusos de funcionalidad y las cadenas multi-paso son territorio humano. Lo que sí evita es gastar tiempo del pentest en clases conocidas que el escáner ya tendría que haber cazado.
Un WAF delante puede ensuciar el resultado. Es habitual ejecutar DAST contra una ruta que salta el WAF (preprod, IP allowlist) para no medir el WAF y medir la aplicación. Si se prueba contra producción detrás del WAF, conviene reportarlo así para no confundir bloqueo con corrección.
Ejemplo: DAST en una empresa con varias aplicaciones web y APIs
Una empresa con cuatro aplicaciones web y una docena de microservicios expuestos vía API decide introducir DAST en su programa de seguridad. La pipeline arranca el escáner contra staging cada noche con tres modos: anónimo (rutas públicas), autenticado como usuario estándar y autenticado como administrador. Para las APIs se conecta la especificación OpenAPI versionada en el repositorio y se ejecuta una pasada por contrato. El resultado entra en el sistema de gestión de hallazgos junto con los de SAST y los del escáner externo, deduplicado y enriquecido con criticidad del activo.
En el segundo ciclo aparece un patrón interesante: tres de las cuatro aplicaciones tienen XSS reflejado en formularios que el equipo había marcado como saneados; el escáner lo encuentra porque prueba con un conjunto amplio de cargas que el desarrollador no había contemplado. La cuarta tiene una redirección abierta en el flujo de login que sirve como pivote ideal para una campaña de phishing. La auditoría manual posterior ya no gasta tiempo en esos vectores: se centra en lógica de negocio y permisos, y encuentra dos fallos de autorización en API que ninguna herramienta automatizada habría detectado. El programa entrega tres planos accionables (SAST, DAST, pentest) que se complementan en lugar de duplicarse.
Errores habituales
- Lanzar DAST anónimo y dar por hecho que se ha probado la aplicación. Sin sesión autenticada el escáner solo ve la portada y el formulario de login. La cobertura real necesita usuarios de prueba con permisos distintos y, en APIs, el contrato OpenAPI.
- Ejecutar DAST contra producción detrás del WAF sin avisarlo. El informe acaba midiendo el WAF y no la aplicación; los hallazgos parecen menores cuando en realidad el bloqueo viene de un control externo que puede caer.
- Confiar solo en spider para descubrir endpoints. Las APIs y las rutas dinámicas no aparecen así. Sin spec o sin sitemap manual, queda fuera la parte de la aplicación con más lógica de negocio.
- Ignorar los falsos positivos en lugar de gestionarlos. El equipo de desarrollo se cansa rápido si la herramienta marca todo como crítico. Sin proceso para marcar y firmar falsos positivos con caducidad, DAST pierde credibilidad.
- Asumir que DAST cubre OWASP Top 10 por completo. Cubre bien inyecciones, XSS, redirecciones abiertas y cabeceras; cubre mal autorización rota, lógica de negocio y autenticación multi-paso. Esa parte vive en el pentest.
Términos relacionados
Servicios relacionados
Este concepto puede tener relación con servicios como:
Preguntas frecuentes
¿En qué se diferencia DAST de SAST?
DAST analiza la aplicación en ejecución como una caja negra: ve configuración real, autenticación efectiva y comportamiento del runtime. SAST analiza el código sin ejecutarlo: ve lógica interna, rutas no alcanzables y secretos pegados en el repositorio. Son complementarios y un programa serio de seguridad de aplicaciones combina los dos.
¿DAST cubre el OWASP Top 10 entero?
Cubre bien inyecciones, XSS, redirecciones abiertas, configuración por defecto y cabeceras de seguridad. Cubre mal autorización rota, fallos de lógica de negocio y cadenas multi-paso. Esa parte exige pentesting manual; DAST despeja terreno para que el pentest se concentre donde aporta valor.
¿Hace falta credenciales para que DAST aporte valor?
Sí. Sin sesión autenticada el escáner recorre la zona pública y deja sin probar la mayor parte de la aplicación. Conviene preparar usuarios de prueba con permisos distintos (usuario, admin, lectura) y, en APIs, conectar el contrato OpenAPI para que el escáner genere peticiones válidas.
¿Puedo lanzar DAST contra producción?
Se puede, pero hay que tomar dos precauciones. Avisar al equipo de operaciones para que no confunda el escáner con un ataque, y decidir si se prueba detrás del WAF (mide la aplicación + el WAF) o saltándolo (mide solo la aplicación). En general conviene probar contra staging idéntico a producción y, si se hace en producción, sin destructive scans.
¿Cómo se integra DAST en CI/CD?
El patrón habitual es lanzar un escáner ligero contra el entorno efímero de cada pull request para detectar regresiones grandes, y un escáner completo nocturno contra staging. El gating bloqueante suele reservarse a categorías críticas (inyección, autenticación rota); para el resto, el informe sirve al equipo sin frenar la entrega.