DAST: Encuentra Vulnerabilidades que SAST No Ve (Guía Práctica 2026)

Tu aplicación pasa la revisión de código. Los tests unitarios están en verde. El escáner SAST no encuentra nada crítico. El equipo da luz verde al despliegue y la nueva versión llega a producción. Dos semanas después, alguien explota una inyección SQL en el formulario de búsqueda. El SAST no la detectó porque, en el código fuente, la query se construye de forma dinámica a través de tres capas de abstracción y dos middlewares que solo interactúan en tiempo de ejecución.

No es un caso inventado. Es algo que vemos constantemente. Las herramientas de análisis estático son buenas encontrando patrones de código potencialmente inseguros. Pero no pueden ejecutar la aplicación. No saben qué pasa cuando un usuario mete un ' OR 1=1 -- en un campo de texto, porque nunca lo prueban contra la aplicación real. Solo leen código.

Aquí es donde entra DAST. En lugar de leer el código fuente, lanza peticiones reales contra tu aplicación desplegada y analiza las respuestas. Si hay una inyección SQL, la encuentra. Si una cabecera de seguridad está ausente, la reporta. Si un endpoint devuelve datos que no debería, lo detecta. Porque no está leyendo planos: está probando el edificio terminado.

Vamos a explicar qué es DAST, qué detecta, cómo se compara con SAST e IAST, y cómo encaja en un pipeline de desarrollo moderno.

Si ya estás buscando cubrir esto en un proyecto concreto, Vulnerabbit ofrece DAST continuo para aplicaciones web y APIs con integración nativa en CI/CD — puedes ver la plataforma DAST o lanzar un escaneo gratuito contra tu dominio sin instalar nada.

¿Qué es DAST? Respuesta rápida

DAST (Dynamic Application Security Testing) es una técnica de análisis de seguridad que examina aplicaciones web y APIs en ejecución, interactuando con ellas desde fuera como lo haría un atacante, sin necesitar acceso al código fuente.

DAST detecta vulnerabilidades del OWASP Top 10 — inyecciones SQL, XSS, autenticación rota, exposición de datos, control de acceso — a través de pruebas automatizadas contra la aplicación desplegada. Es especialmente útil para cobertura continua en pipelines de CI/CD.

DAST se diferencia de SAST (Static Application Security Testing) en que SAST analiza código fuente sin ejecutar la aplicación, mientras que DAST prueba la aplicación en ejecución. Son complementarios: SAST encuentra errores de código; DAST encuentra errores de configuración y runtime.

---

Qué es DAST (Dynamic Application Security Testing)

DAST, o pruebas dinámicas de seguridad de aplicaciones, es una metodología de testing que analiza una aplicación en ejecución desde el exterior. No necesita acceso al código fuente ni al entorno de desarrollo. Trabaja exactamente como lo haría un atacante: enviando peticiones HTTP contra la aplicación, manipulando parámetros, inyectando payloads y analizando cómo responde.

La diferencia fundamental con un análisis estático (SAST) es la perspectiva. SAST examina el código fuente línea por línea buscando patrones que podrían ser vulnerables: una query SQL concatenada con input del usuario, un hash MD5 para contraseñas, un token hardcodeado. Encuentra problemas potenciales antes de que el código se ejecute. DAST no ve el código. Solo ve la aplicación desplegada, exactamente igual que cualquier usuario o atacante.

La analogía más clara que hemos encontrado: SAST es como revisar los planos de un edificio para comprobar que cumple las normas de protección contra incendios. DAST es entrar en el edificio y comprobar si realmente puedes provocar un incendio. Los planos pueden decir que hay un extintor en cada planta, pero DAST verifica que los extintores están ahí y que funcionan.

Esto tiene implicaciones importantes. SAST puede detectar una vulnerabilidad en código que nunca se ejecuta en producción, generando un falso positivo. DAST solo detecta lo que realmente es explotable en la aplicación desplegada. Por otro lado, DAST necesita que la aplicación esté en funcionamiento, lo que significa que suele ejecutarse más tarde en el ciclo de desarrollo: contra staging o pre-producción.

DAST cubre aplicaciones web, APIs REST y, dependiendo de la herramienta, endpoints GraphQL — cualquier servicio que responda por HTTP. No importa en qué lenguaje esté escrita la aplicación ni qué framework use. Para DAST, tu aplicación es una caja negra que acepta peticiones y devuelve respuestas. Lo que pase dentro es irrelevante: lo que importa es el comportamiento observable.

---

Qué detecta DAST

Las pruebas dinámicas son especialmente eficaces para detectar vulnerabilidades que solo se manifiestan en tiempo de ejecución. Estas son las categorías principales, mapeadas al OWASP Top 10:

Inyección SQL (A03:2021 — Injection)

DAST envía payloads de inyección en cada parámetro de entrada: campos de formulario, parámetros de URL, cabeceras, cookies. Si la aplicación es vulnerable, la respuesta lo delata: errores de base de datos, cambios en el comportamiento, tiempos de respuesta anómalos (en el caso de inyecciones ciegas basadas en tiempo). Un escáner SAST puede no detectar una inyección SQL si la query se construye dinámicamente a través de un ORM con configuración insegura. DAST la encuentra porque la prueba directamente.

XSS reflejado y almacenado (A03:2021 — Injection)

El escáner inyecta scripts en campos de entrada y comprueba si aparecen sin sanitizar en la respuesta HTML. Para XSS almacenado, envía el payload, luego navega a la página donde debería renderizarse y verifica si se ejecuta. Esto incluye tanto XSS en el DOM como en respuestas del servidor.

CSRF en formularios críticos (fuera del OWASP Top 10 2021, pero sigue siendo un hallazgo frecuente)

DAST verifica si los formularios que realizan acciones sensibles (cambio de contraseña, transferencias, modificación de datos) incluyen tokens anti-CSRF válidos. Si puedes enviar un formulario desde un dominio externo y la acción se ejecuta, tienes un problema. CSRF fue eliminado del OWASP Top 10 en la revisión de 2021, pero sigue siendo una vulnerabilidad real que DAST detecta de forma rutinaria.

Cabeceras de seguridad ausentes

Cada respuesta HTTP se analiza para comprobar la presencia y configuración correcta de cabeceras de seguridad:

• Content-Security-Policy (CSP): sin ella, los ataques XSS son mucho más fáciles de explotar
• Strict-Transport-Security (HSTS): sin ella, un atacante en la red puede forzar una conexión HTTP en lugar de HTTPS
• X-Frame-Options o directiva frame-ancestors en CSP: sin ella, tu aplicación es vulnerable a clickjacking
• X-Content-Type-Options: previene que el navegador interprete archivos con un MIME type diferente al declarado

Configuraciones inseguras expuestas (A05:2021 — Security Misconfiguration)

DAST busca activamente señales de configuraciones que no deberían estar visibles en producción:

• Cabeceras Server o X-Powered-By que revelan tecnología y versión exacta
• Páginas de error que muestran stack traces con rutas internas del servidor
• Paneles de debug accesibles (/debug, /elmah, /phpinfo.php)
• Directory listing habilitado en directorios que contienen archivos sensibles
• Endpoints de health check o métricas expuestos sin autenticación

IDOR y BOLA en APIs (A01:2021 — Broken Access Control)

Este es uno de los hallazgos más críticos en APIs modernas. DAST manipula identificadores en las peticiones (cambia user_id=123 por user_id=124) y comprueba si la API devuelve datos de otro usuario. Los problemas de control de acceso son difíciles de detectar con SAST porque dependen de la lógica de negocio y del estado de la sesión. DAST los encuentra porque los prueba con peticiones reales.

El enfoque más efectivo es el escaneo con conocimiento de especificación (spec-aware scanning). En lugar de hacer fuzzing ciego contra endpoints, un escáner DAST avanzado parsea tu especificación OpenAPI/Swagger para entender la estructura de tu API: qué endpoints existen, qué parámetros aceptan, qué roles deberían tener acceso a cada uno. Con esa información, crea sesiones autenticadas con diferentes roles (admin, usuario A, usuario B) e intenta accesos cruzados de forma sistemática.

La diferencia es enorme. Un escáner genérico prueba GET /api/users/123 cambiando el ID. Un escáner spec-aware sabe que ese endpoint requiere rol admin, crea una sesión con rol user, e intenta el acceso — validando la lógica de autorización, no solo la existencia del endpoint. Esto es lo que diferencia encontrar un IDOR real de generar falsos positivos.

Si tu aplicación expone una API, vale la pena revisar los riesgos específicos del OWASP API Security Top 10 para entender qué más puede detectar un escáner dinámico bien configurado. Y si quieres ir más allá de las pruebas técnicas tradicionales, nuestra solución de seguridad de APIs cubre el OWASP API Top 10 completo con pruebas contextuales de autorización.

---

DAST vs SAST vs IAST

La pregunta de "¿cuál es mejor?" es la pregunta equivocada. Cada metodología detecta cosas diferentes, en momentos diferentes del ciclo de desarrollo. Son complementarias, no competidoras.

SAST es tu primera línea de defensa. Se ejecuta en cada commit o pull request y detecta problemas en el código antes de que llegue a ningún entorno. Su debilidad: muchos falsos positivos y no puede detectar problemas que solo aparecen en runtime.

DAST es tu verificación de la realidad. Se ejecuta contra la aplicación desplegada y confirma qué es realmente explotable. Su debilidad: necesita que la aplicación esté funcionando y es más lento que SAST.

IAST combina ambos enfoques: instrumenta el runtime de la aplicación con un agente que observa el flujo de datos mientras los tests funcionales se ejecutan. Sabe qué línea de código procesa cada petición, así que puede correlacionar un input malicioso con el código vulnerable exacto. Su debilidad: necesita un agente que soporte tu stack tecnológico y tests funcionales con buena cobertura.

La combinación ideal es SAST en el pipeline de CI para feedback rápido, DAST contra staging antes de promover a producción, y IAST integrado en los tests funcionales si tu stack lo permite. No son alternativas: cada una cubre los puntos ciegos de las otras.

---

Cuándo necesitas DAST

Hay cuatro escenarios claros en los que DAST no es opcional sino necesario:

Antes de cada despliegue a producción

El caso de uso más directo. Después de desplegar en staging, ejecutas un escaneo DAST contra la nueva versión. Si aparecen hallazgos de severidad alta o crítica, el despliegue a producción se bloquea hasta que se corrijan. Esto es especialmente importante para aplicaciones que manejan datos personales o financieros, donde una vulnerabilidad explotable en producción puede significar una brecha de datos con consecuencias regulatorias.

Escaneos de cumplimiento periódicos

ISO 27001 (control A.8.8), ENS y NIS2 exigen evaluaciones de vulnerabilidades técnicas de forma periódica. DAST genera evidencias directas de que estás evaluando la seguridad de tus aplicaciones contra las vulnerabilidades conocidas. Los informes de un escaneo DAST se pueden presentar directamente como evidencia en auditorías de certificación.

Antes de un test de penetración

Un pentest manual cuesta entre 5.000 y 20.000 euros dependiendo del alcance. Si el pentester dedica las primeras horas a encontrar cabeceras de seguridad ausentes, formularios sin protección CSRF y un directory listing habilitado, estás pagando precio de pentester por hallazgos que un escáner DAST encuentra en minutos. Ejecutar DAST antes del pentest limpia los hallazgos fáciles y permite que el pentester se centre en la lógica de negocio y los ataques complejos que justifican su tarifa. Hemos escrito más sobre esta diferencia en nuestro artículo sobre pruebas de penetración manuales vs automatizadas.

Al integrar servicios de terceros

Cuando conectas tu aplicación a una nueva pasarela de pago, un proveedor de identidad o cualquier servicio externo, estás añadiendo una superficie de ataque nueva. Los endpoints de callback, los flujos de OAuth, los webhooks: todo esto necesita validación de seguridad. DAST contra el entorno de staging con la nueva integración te da visibilidad sobre problemas antes de que lleguen a producción.

---

DAST en tu pipeline CI/CD

Integrar DAST en el pipeline de CI/CD transforma las pruebas de seguridad de un evento puntual a un proceso continuo. La diferencia es la misma que entre hacer un chequeo médico una vez al año y monitorizar tus constantes vitales continuamente.

El flujo típico es el siguiente. Tras un merge a la rama principal, el pipeline despliega automáticamente en staging. Una vez que staging está activo, se lanza el escaneo DAST contra esa instancia. El escáner prueba la aplicación durante un tiempo definido (normalmente entre 10 y 45 minutos dependiendo del tamaño de la aplicación). Cuando termina, los resultados se publican como comentario en la pull request o como artefacto del pipeline.

Lo más importante es definir qué pasa con los resultados. Una configuración eficaz establece políticas claras: si el escaneo encuentra hallazgos de severidad CRITICAL o HIGH, el pipeline se bloquea y no se puede promover a producción. Los hallazgos MEDIUM generan tickets automáticos para revisión. Los LOW se acumulan en un dashboard para revisión periódica.

En equipos que usan GitHub Actions, el flujo se integra con pasos que esperan al despliegue en staging, lanzan el escaneo, y evalúan los resultados contra la política definida. No es necesario que el escaneo sea exhaustivo en cada commit: un escaneo rápido contra las rutas principales en cada merge y un escaneo completo nocturno cubren la mayoría de riesgos sin ralentizar el flujo de desarrollo.

La clave es que el equipo de desarrollo vea los resultados de DAST como parte normal de su flujo de trabajo, no como algo que lanza el equipo de seguridad una vez al trimestre y genera un PDF que nadie lee. Cuando los hallazgos de seguridad aparecen en la misma interfaz que el resto de la integración continua, la seguridad deja de ser un silo.

---

Limitaciones de DAST

DAST es una herramienta potente, pero no lo encuentra todo. Es importante ser transparentes sobre sus limitaciones para que sepas qué esperar y qué cubrir con otras herramientas.

No detecta errores de lógica de negocio. DAST puede verificar que un endpoint requiere autenticación y que los parámetros no son vulnerables a inyección. Pero no sabe que en tu aplicación un usuario no debería poder aplicar un cupón de descuento dos veces, ni que un pedido con cantidad negativa no debería generar un reembolso. Eso requiere un pentester que entienda tu negocio.

Las zonas autenticadas necesitan configuración. Por defecto, DAST solo analiza lo que puede ver sin iniciar sesión. Para escanear las funcionalidades detrás del login, necesitas proporcionarle credenciales o tokens de sesión. Si no lo configuras, estás dejando sin probar la mayor parte de la aplicación. La buena noticia es que la mayoría de herramientas DAST modernas soportan autenticación con formularios, tokens Bearer, cookies y cabeceras personalizadas.

Es más lento que SAST. Un análisis SAST puede completarse en segundos o minutos. Un escaneo DAST necesita enviar miles de peticiones contra la aplicación y esperar las respuestas. Un escaneo completo puede tardar entre 15 minutos y varias horas dependiendo del tamaño de la aplicación. Esto es aceptable para escaneos nocturnos, pero puede ser un cuello de botella si quieres ejecutarlo en cada commit.

Genera algunos falsos positivos. Menos que SAST, pero los hay. Una cabecera de seguridad que parece ausente puede estar configurada en un reverse proxy que DAST no ve. Un endpoint que parece devolver datos sensibles puede estar protegido por una capa de red que el escáner no atraviesa. La triaje humana sigue siendo necesaria.

---

Cómo funciona DAST en Vulnerabbit

Vulnerabbit incluye DAST como parte de su plataforma de seguridad continua. No es un escáner aislado que genera un informe: está integrado con el resto de la plataforma para darte contexto y priorización real.

Escaneo autenticado. Configuras credenciales de tu aplicación una vez y el escáner accede a todas las funcionalidades protegidas. Soporta login por formulario, tokens OAuth, API keys y cabeceras personalizadas. No necesitas un script personalizado para cada flujo de autenticación.

Cobertura OWASP Top 10 completa. Cada escaneo prueba las categorías del OWASP Top 10 2021: inyecciones, XSS, configuraciones inseguras, control de acceso, componentes vulnerables y el resto de categorías.

Priorización por explotabilidad real. No todas las vulnerabilidades son iguales. Un XSS reflejado en una página de error interna es menos urgente que una inyección SQL en el formulario de registro. Vulnerabbit prioriza los hallazgos combinando la severidad técnica con el contexto de la aplicación.

Guías de remediación del Security Copilot. Para cada hallazgo, el Security Copilot genera una explicación clara de qué pasa, por qué es un riesgo y cómo arreglarlo con código específico para tu stack tecnológico. No un enlace genérico a la documentación de OWASP, sino una guía adaptada a tu situación.

Integración CI/CD. Conecta tu pipeline de GitHub Actions y ejecuta escaneos automáticos tras cada despliegue en staging. Los resultados aparecen como comentarios en la pull request con la severidad de cada hallazgo.

Puedes ver los detalles de nuestra solución DAST en la página de DAST.

---

---

DAST como Parte de tu Estrategia de Seguridad Continua

DAST no trabaja solo. En una estrategia de seguridad madura, se combina con otras disciplinas:

• EASM (External Attack Surface Management) para descubrir qué activos tienes expuestos antes de escanearlos
• CSPM para auditar configuraciones cloud desde dentro
• Seguridad de APIs para pruebas de autorización (BOLA/IDOR) específicas de tu lógica de negocio
• ISO 27001 controles técnicos si necesitas mapear DAST a controles de compliance (A.8.25, A.8.28)

La clave es que cada herramienta cubre los puntos ciegos de las otras. EASM te dice qué tienes. DAST te dice si es seguro. CSPM verifica que la configuración subyacente es correcta.

---

Conclusión

DAST prueba tu aplicación como la probaría un atacante: desde fuera, con peticiones reales, contra la aplicación desplegada. Encuentra lo que SAST no puede ver porque no ejecuta código, y lo que un pentest manual no cubre porque no se ejecuta cada semana.

No sustituye al análisis estático ni al pentesting. Los complementa. SAST te da feedback rápido en cada commit. DAST verifica que la aplicación desplegada es segura. Un pentester encuentra los problemas de lógica que ninguna herramienta automatizada detecta. Los tres juntos cubren el espectro completo.

Si tu equipo despliega código con frecuencia y no tiene DAST en el pipeline, estás confiando en que todo lo que puede salir mal se detecta en el código fuente. Y como hemos visto, eso no siempre es así. Las vulnerabilidades más peligrosas son las que solo aparecen cuando la aplicación está funcionando. DAST es la herramienta que las encuentra.

---

¿Necesitas DAST en tu pipeline ya mismo?

La plataforma DAST de Vulnerabbit integra con GitHub Actions, GitLab y Bitbucket, y exporta evidencia directa para auditoría ISO 27001.

Lanzar escaneo gratuito → · Ver /solutions/dast →