DAST (pruebas dinámicas de seguridad de aplicaciones) prueba una aplicación en ejecución desde fuera para encontrar debilidades. Esta página explica en qué se diferencia de otros métodos y cómo usarlo en tu propia aplicación (no cubre la prueba de sitios de otras personas).
Qué es DAST
DAST significa pruebas dinámicas de seguridad de aplicaciones. La Guía DevSecOps de OWASP lo describe como pruebas de caja negra que encuentran vulnerabilidades y debilidades de seguridad en una aplicación en ejecución. Caja negra significa probar solo a través de lo que es visible desde fuera, sin revisar el código fuente interno.
En la práctica, una herramienta recorre las páginas y los campos de entrada de la aplicación, envía solicitudes de prueba y busca indicios de problemas en las respuestas. La guía indica que es especialmente útil para la validación de entradas y salidas, los problemas de autenticación y los errores de configuración del servidor.
Cómo funciona
En qué se diferencia de SAST, IAST y SCA
| Método | Qué examina | ¿Ejecuta la aplicación? | Ideal para |
|---|---|---|---|
| DAST | El comportamiento de la aplicación en ejecución desde fuera | Sí | Validación de entradas y salidas, autenticación, configuración del servidor |
| SAST | Código fuente o código compilado | No | Encontrar problemas de codificación al inicio del desarrollo |
| IAST | El comportamiento interno de la aplicación (mediante sensores) | Sí (durante las pruebas) | Problemas que aparecen durante las pruebas automatizadas |
| SCA | Bibliotecas y otras dependencias | No | Componentes con vulnerabilidades conocidas (CVE) |
Para SAST, OWASP enumera limitaciones como encontrar solo un porcentaje relativamente pequeño de fallos de seguridad de aplicaciones, muchos falsos positivos y problemas de configuración no detectados. DAST ayuda a cubrir esa brecha, pero tampoco es completo. Para SCA, consulta auditar dependencias con OSV-Scanner.
Cómo usarlo en tu propia aplicación (ejemplo con OWASP ZAP)
ZAP (Zed Attack Proxy; antes llamado OWASP ZAP) es una herramienta DAST gratuita y de código abierto. Su sitio oficial la identifica ahora como "ZAP by Checkmarx".
- Prepara la URL de un entorno de prueba que administres. Usa un entorno de prueba, no producción
- Ejecuta un escaneo base. Según la documentación de ZAP, es solo pasivo: ejecuta el spider (la función que recorre las páginas) durante 1 minuto por defecto y no realiza ataques. Tarda unos pocos minutos como máximo
- Revisa los resultados y pide a una persona que confirme cuáles son reales; los falsos positivos ocurren
- Si es necesario, pasa a un escaneo activo, solo en un entorno de prueba. Ejecuta ataques conocidos contra el objetivo, y la documentación indica que no debe usarse en aplicaciones web que no sean de tu propiedad
- Repítelo con regularidad, por ejemplo en CI, después de cada corrección
Solo contra entornos de prueba de aplicaciones que posees o administras
Las herramientas DAST envían tráfico que se parece a ataques reales. Ejecutarlas en un sitio que no tienes permiso para probar puede considerarse acceso no autorizado o interrupción del servicio. La documentación de ZAP también indica que no se debe usar el escaneo activo en aplicaciones web que no sean de tu propiedad. Ejecutarlo en producción también puede tener efectos secundarios, como crear datos o añadir carga.
Lo que DAST no detecta
La documentación de ZAP indica que su escaneo activo no puede encontrar problemas lógicos, como el control de acceso roto, por lo que debe complementarse con pruebas manuales. Un fallo como IDOR, en el que un usuario puede ver los datos de otro, es difícil para una herramienta automatizada porque no sabe cuál es el comportamiento correcto. Necesitas escribir tu propia prueba que solicite el ID de otro usuario y confirme que se rechaza.
Las comprobaciones de configuración, en cambio, son algo en lo que DAST es bueno. Para saber qué vale la pena configurar, consulta cabeceras de seguridad: lo que sigue importando.
Opinión de este sitio: DAST es la última red. Piensa en tres capas: código, componentes y comportamiento
Es más realista combinar tres métodos que miran en lugares distintos que esperar que una sola herramienta lo encuentre todo: leer el código (SAST), revisar los componentes en busca de vulnerabilidades conocidas (SCA) y, después, ejecutar la aplicación y probarla desde fuera (DAST). Lo que las herramientas no hacen bien, "quién puede hacer qué", lo proteges con pruebas que escribes tú mismo. No confíes en los resultados de la herramienta sin revisarlos; haz que una persona los confirme antes de corregir.
Fuentes (primarias)
- Guía DevSecOps de OWASP, "Dynamic Application Security Testing" — owasp.github.io (definición de DAST, caja negra)
- Guía DevSecOps de OWASP, "Interactive Application Security Testing" — owasp.github.io (IAST)
- Comunidad OWASP, "Source Code Analysis Tools" — owasp.org (SAST y sus límites)
- Documentación de ZAP, "Active Scan" — zaproxy.org (no para aplicaciones que no sean de tu propiedad; no puede encontrar problemas lógicos)
- Documentación de ZAP, "Baseline Scan" — zaproxy.org (solo pasivo; tiempo de ejecución)
- La descripción de SCA es una definición general; no se verificó ninguna definición oficial única para ella
Lecturas recomendadas
- Glosario: Qué es el fuzzing · Qué es el OWASP Top 10 · Qué es IDOR
- Guías: Cabeceras de seguridad: lo que sigue importando · Auditar dependencias con OSV-Scanner
- Glosario: Qué es un CVE