DAST (Pruebas dinámicas de seguridad de aplicaciones).

Las herramientas DAST interactúan con una aplicación desplegada —normalmente vía HTTP— sin necesidad de código fuente. Rastrean endpoints, envían peticiones maliciosas y observan respuestas para detectar inyección SQL, XSS, SSRF, fallos de autenticación, CORS mal configurado o cookies inseguras. Como ven lo mismo que un atacante, complementan al SAST capturando problemas que solo aparecen en ejecución, incluidos los derivados de configuración, infraestructura o servicios externos. Suelen ejecutarse en entornos de staging o QA e integrarse en CI/CD como control de liberación. Herramientas habituales: OWASP ZAP, Burp Suite, Invicti, Acunetix y StackHawk.

Cómo funciona

Un escaneo DAST se ejecuta en dos fases. Primero, un rastreador (spider) mapea la superficie de ataque de la aplicación siguiendo enlaces, analizando JavaScript y reproduciendo tráfico grabado para descubrir formularios, parámetros y rutas de API. Segundo, un escáner activo muta cada entrada con cargas de ataque e infiere vulnerabilidades a partir de los códigos de respuesta, los tiempos, el contenido reflejado o las firmas de error; por ejemplo, una inyección SQL ciega basada en tiempo se confirma cuando una carga SLEEP() retrasa la respuesta de forma medible.

El DAST moderno ha evolucionado hacia el escaneo orientado a API y autenticado: las aplicaciones de página única y los backends REST/GraphQL exponen poco a un rastreador ingenuo, por lo que los escáneres consumen especificaciones OpenAPI/Swagger y emplean secuencias de inicio de sesión programadas para alcanzar funcionalidad protegida. La cobertura suele contrastarse con la OWASP Web Security Testing Guide (WSTG). Los límites del DAST importan igual de mucho: no aporta la ubicación en la línea de código, no puede ver rutas de código inalcanzables y corre el riesgo de falsos negativos ante estados complejos del lado del cliente; por eso los equipos lo combinan con SAST e IAST en lugar de depender solo de él. Para evitar escanear producción y provocar efectos secundarios reales (envío de correos, realización de pedidos), los escaneos se restringen a objetivos fuera de producción y se les asigna un alcance definido y una lista de exclusiones.

flowchart LR
  A[Aplicación en ejecución<br/>staging/QA] --> B[Rastreador / spider<br/>mapea endpoints]
  B --> C[Escáner activo<br/>inyecta cargas]
  C --> D{¿Anomalía en<br/>la respuesta?}
  D -->|Sí| E[Reportar hallazgo<br/>SQLi / XSS / SSRF]
  D -->|No| F[Marcar endpoint limpio]
  E --> G[Control CI/CD<br/>fallar build / triaje]