Las Pruebas Dinámicas de Seguridad de Aplicaciones, Dynamic Application Security Testing (DAST) buscan vulnerabilidades de seguridad en una aplicación en ejecución. El escáner no necesita código fuente: envía peticiones a endpoints vivos y lee lo que regresa, igual que haría un atacante sondeando desde afuera. OWASP señala que las pruebas dinámicas puede correrlas una herramienta o una persona, y que las dos encuentran cosas distintas.
El escáner DAST de Fluid Attacks prueba siete superficies de ataque: registros DNS, cabeceras, contenido HTML, conexiones SSL, endpoints HTTP no autenticados, webhooks y WebSockets. No prueba endpoints autenticados. En el State of Attacks 2026 de Fluid Attacks, construido sobre 1.119.396 vulnerabilidades reportadas en sistemas de clientes durante 2025, la debilidad más frecuente en aplicaciones fue la ausencia o evasión del mecanismo de autenticación, con una exposición al riesgo promedio de 855,99 CVSSF. La distancia entre lo que alcanza un escáner y dónde está el riesgo es el argumento de todo lo que viene después del escaneo.
Esta página cubre qué alcanza un escaneo DAST y qué no, cómo se mide su precisión, cómo lo corre Fluid Attacks, cómo integrarlo a un pipeline y el punto donde las pruebas manuales toman el relevo.
¿Qué es DAST?
DAST es una técnica de pruebas de seguridad de caja negra: evalúa una aplicación mientras esa aplicación está corriendo, sin ver el código fuente que tiene detrás. Como trabaja desde afuera, es independiente del lenguaje y corre igual contra el código que escribiste y el que compraste.
Un escaneo tiene cuatro etapas: mapea y rastrea el objetivo para encontrar páginas, parámetros y endpoints; envía payloads de ataque a las entradas que encontró; lee las respuestas en busca de errores, contenido inesperado, cambios de tiempo o accesos no autorizados; y reporta lo que confirmó, con la petición y la respuesta como evidencia.
Qué no es DAST
No es un lector de código. Un hallazgo de DAST te dice que una aplicación se comporta de forma insegura, no qué línea produjo ese comportamiento. Esa limitación es estructural, no un vacío del producto, y tiene consecuencias concretas en las herramientas: más abajo está el problema de la pestaña Security de GitHub.
Tampoco es exhaustivo. Un escáner solo prueba lo que alcanza: las rutas detrás de un login, los caminos de código que un rastreador nunca dispara y los flujos que dependen del estado del negocio quedan sin probar a menos que algo más los cubra. La documentación de Fluid Attacks indica que ni su escáner ni sus pentesters soportan DOM APIs.
Por qué importa DAST
Las vulnerabilidades en ejecución son las que una base de código correcta puede seguir cargando. La configuración del despliegue, los ajustes de TLS, las cabeceras de respuesta, el manejo de sesiones y las integraciones con terceros no tienen una línea de código que inspeccionar, y solo existen cuando la aplicación está arriba.
La configuración falla donde no vive el código fuente
Dos reglas de detección de Fluid Attacks lo muestran. DAST-SCNRY reporta una vulnerabilidad “when the Content-Security-Policy header is completely missing from the HTTP response”. DAST-TNTER lee el valor de la CSP y marca una directiva script-src ausente o configuraciones inseguras como unsafe-inline o unsafe-eval. Las dos están clasificadas como WEB DAST, con HTTP como objetivo y HEADERS como tecnología.
Ninguno de los dos hallazgos existe en el repositorio. Existen en la respuesta.
El volumen no es el riesgo
Las herramientas automatizadas encuentran la mayoría de los problemas y una parte menor del peligro. En el State of Attacks 2026, las herramientas automatizadas de Fluid Attacks identificaron el 88,4 % de todas las vulnerabilidades reportadas, pero el 55,8 % de la exposición total al riesgo; las pruebas manuales aportaron el 11,6 % restante de las vulnerabilidades y el 44,2 % de la exposición. Para las vulnerabilidades de severidad crítica, el 87 % se identificó mediante revisión manual. Eso es una división del trabajo, no un veredicto sobre las herramientas: un escáner despeja el terreno rápido, y no es lo que encuentra el problema que termina en el reporte de incidentes.
Las aplicaciones son el objetivo que los equipos corrigen más rápido
El mismo reporte cuenta 140.551 vulnerabilidades en el objetivo “Application”, con 3.903.585,51 CVSSF de exposición al riesgo, y las aplicaciones fueron el objetivo más rápido de remediar: al menos el 40 % de sus vulnerabilidades se corrigió en 30 días. Los hallazgos que llegan con una petición reproducible tienden a moverse, porque un desarrollador puede repetirlos.
DAST en Fluid Attacks
Fluid Attacks corre Dynamic Application Security Testing como un escáner automatizado y Pentesting as a Service (PTaaS) como pruebas manuales. La documentación plantea la división en dos frases: “DAST is an automated scanner. In PTaaS, pentesters test applications manually”. Lo que sigue es qué superficies alcanza cada uno, cómo se configura el escaneo y los dos puntos donde se detiene.
Qué alcanza el escáner y dónde entra el pentester
El escáner alcanza siete superficies; ocho más necesitan un pentester.
Superficie de ataque | DAST automatizado | PTaaS |
|---|---|---|
Registros DNS | Sí | Sí |
Cabeceras | Sí | Sí |
Contenido HTML | Sí | Sí |
Conexiones SSL, suites de cifrado, protocolos, certificados X509 | Sí | Sí |
Endpoints HTTP no autenticados | Sí | Sí |
Webhooks | Sí | Sí |
WebSockets | Sí | Sí |
Endpoints HTTP autenticados | No | Sí |
APIs REST, SOAP, GraphQL y gRPC | No | Sí |
Especificaciones OpenAPI, Swagger y Postman | No | Sí |
DOM APIs | No | No |
Fuente: superficies de ataque soportadas de Fluid Attacks. PTaaS está disponible exclusivamente en el plan Advanced.
La respuesta honesta a “¿puede DAST probar APIs?” depende de a qué herramienta te refieras. El escáner web se distribuye como el contenedor Docker fluidattacks/dast y cubre las siete superficies de arriba. Una herramienta aparte, dast_api, se distribuye como binario y “scans API endpoints declared in a Postman collection”. El roadmap de Fluid Attacks lista el DAST automatizado para APIs como trabajo en curso, así que hasta que salga, las especificaciones de API las cubren los pentesters.
Cómo se ve en la práctica
Elemento | Cómo funciona |
|---|---|
Escáner web | Contenedor Docker fluidattacks/dast |
Pruebas de seguridad de APIs | dast_api, un binario distribuido que no escanea sin una credencial |
Alcance | dast.urls — “Each entry must have a url field. It can also have an optional environment_id field” |
Comprobación de conectividad | dast.strict_connectivity, por defecto false. En true, “the scanner exits with a non-zero status code if it cannot connect to a configured endpoint” |
Pipeline de CI/CD | DAST GitHub Action, o la CLI en cualquier runner con Docker |
Salida | SARIF o CSV, leída como artefacto del workflow |
Control del build | CI Gate, que rompe el build cuando un hallazgo incumple tu política |
Verificación | Reattack, que vuelve a probar una vulnerabilidad tras un intento de corrección |
Activa strict_connectivity. Sin él, un escaneo que nunca alcanzó el objetivo devuelve limpio, y eso se lee exactamente igual que un escaneo que no encontró nada.
Por qué los hallazgos de DAST no caben en la pestaña Security de GitHub
La documentación de Fluid Attacks es directa: “You cannot upload DAST findings to the GitHub Security tab. GitHub’s code scanning API requires a specific file and line number for each vulnerability. Web application vulnerabilities detected at runtime do not have this information”. En su lugar, configura output.format: SARIF o CSV y lee la salida del escáner como artefacto del workflow. Conviene saberlo antes de diseñar un tablero alrededor de una pestaña que va a quedar vacía.
La autenticación es donde el escáner entrega el relevo
La ausencia o evasión de autenticación lidera, con 855,99 de exposición promedio.
Medida | Herramientas automatizadas | Pruebas manuales |
|---|---|---|
Parte de las vulnerabilidades reportadas | 88,4 % | 11,6 % |
Parte de la exposición total al riesgo | 55,8 % | 44,2 % |
Parte de las vulnerabilidades críticas identificadas | — | 87 % |
Exposición al riesgo de críticas detectada | — | 90 % |
Fuente: State of Attacks 2026 de Fluid Attacks, que cubre del 1 de enero al 31 de diciembre de 2025.
Pon los dos hechos uno al lado del otro. El DAST automatizado prueba endpoints HTTP no autenticados. La debilidad que lidera el objetivo Application es la ausencia o evasión del mecanismo de autenticación. El escáner confirma que un recurso protegido está efectivamente protegido frente a un visitante anónimo; no inicia sesión como dos usuarios distintos para comprobar si uno puede leer los registros del otro, que es lo que exige la referencia insegura a objetos.
El benchmark le pone un número a esa misma brecha. De las 1.201 vulnerabilidades sembradas en esa aplicación de prueba, el 73,2 % requería autenticación para ser alcanzada.
Por eso PTaaS existe como una oferta aparte y no como un nivel premium del mismo escaneo.
Verificar la corrección es parte de la prueba
Un reporte no es un resultado. La documentación de Fluid Attacks lo dice sin rodeos: “As part of vulnerability management, examine the code again after each fix. A fix can add new vulnerabilities, or it can fail to fix the original vulnerability”. Reattack hace eso cuando lo solicitas, y la práctica alrededor mueve más la aguja que el escaneo: los sistemas que usan el CI Gate alcanzaron una tasa de remediación del 72,2 %, frente al 58 % de los sistemas que no lo usan.
Para profundizar: pentesting as a service.
Qué alcanza un escaneo DAST y qué se le escapa
Un escaneo confirma una vulnerabilidad de dos maneras. Las pruebas in-band leen la respuesta en la petición misma; las pruebas out-of-band esperan a que el servidor haga la llamada.
Qué examina la regla y cuándo reporta un hallazgo.
Qué se prueba | Ejemplo | Qué confirma |
|---|---|---|
Cabeceras HTTP | DAST-SCNRY | Content-Security-Policy está ausente de la respuesta |
Política de scripts | DAST-TNTER | script-src ausente, unsafe-inline o unsafe-eval |
Autenticación | Un recurso protegido responde a una petición anónima | |
Autorización | Un usuario lee los datos de otro mediante un identificador | |
Transporte | Conexiones SSL | Suites débiles, protocolos obsoletos, certificados inválidos |
La confirmación in-band cubre casi toda esa lista, y se rompe con las vulnerabilidades ciegas: una falsificación de petición del lado del servidor o una inyección de comandos que no devuelve nada al cliente no deja evidencia en el cuerpo de la respuesta. El DAST out-of-band cierra esa brecha con un payload que hace que el objetivo abra una conexión hacia un receptor que controla quien prueba. Los pentesters de Fluid Attacks usan Interactsh, “an open-source tool that finds vulnerabilities that cause out-of-band (OOB) interactions”.
In-band confirma en la respuesta; out-of-band, en una llamada aparte. Elaboración propia.
DAST para APIs
Las pruebas de seguridad de APIs son donde la mayoría de las explicaciones introductorias se vuelven vagas, así que aquí va la versión precisa. Un servicio REST o GraphQL expone operaciones descritas en una especificación, no enlaces que un rastreador pueda seguir, así que DAST las alcanza solo si se le entrega esa especificación: una colección de Postman, un documento OpenAPI o una consulta de introspección.
Los riesgos que importan ahí son riesgos de autorización. El OWASP API Security Top 10 (2023) abre con API1:2023 Broken Object Level Authorization y también lista API2:2023 Broken Authentication y API5:2023 Broken Function Level Authorization. Probar cualquiera de ellos implica tener al menos dos identidades autenticadas y comprobar qué alcanza cada una: un paso de configuración, no un payload.
La filtración de Panera Bread de 2018 muestra qué pasa cuando nadie corre esa prueba. Según reportó Krebs on Security, los registros de clientes estaban en el sitio web de la compañía en texto plano y sin control de acceso, y los identificadores de cuenta eran enteros secuenciales, así que cualquiera podía recorrerlos uno a uno. La falla se reportó el 2 de agosto de 2017 y seguía viva cuando la nota se publicó el 2 de abril de 2018: ocho meses. Krebs escribió que los números incrementales de clientes sugerían que la cifra “may be higher than seven million”, y una actualización posterior la situó en un número que “appears to exceed 37 million”.
Ese caso corta en los dos sentidos. Un endpoint no autenticado que sirve datos de clientes está de lleno dentro de lo que DAST alcanza. La misma falla un login más adentro no lo habría estado.
¿Qué tan preciso es DAST?
La precisión de DAST son cuatro números, no un adjetivo: verdaderos positivos, falsos positivos, falsos negativos y la parte de la aplicación efectivamente cubierta. Una promesa de “pocos falsos positivos” no dice nada sobre el tercero ni el cuarto.
La forma reproducible de comparar herramientas es un conjunto de pruebas fijo y deliberadamente vulnerable. El OWASP Benchmark Project es “a Java and Python test suite designed to verify the speed and accuracy of vulnerability detection tools”, analizable por herramientas estáticas, dinámicas e interactivas por igual, y cada vulnerabilidad que puntúa es explotable. Correr dos escáneres contra el mismo conjunto y publicar los dos scorecards es evidencia; una página de marketing no.
Los conjuntos sintéticos tienen su propio techo, y la brecha se ve en las cifras de Fluid Attacks. En su benchmark de 36 herramientas AppSec de terceros contra una aplicación con 1.201 vulnerabilidades en 105 categorías CWE y 461.500 CVSSF, un pentester encontró 1.076 de ellas: 89,6 % de recall con 100 % de precisión. El mejor evaluador automatizado fue la propia herramienta de Fluid Attacks, que cubre SAST, SCA y DAST a la vez, con 22,7 % de recall y 8,8 % de la exposición total al riesgo. Entre las otras 34 herramientas, el recall promedio fue de 1,7 %.
Un escáner con puntaje perfecto en un benchmark va a seguir perdiéndose la mayor parte de una aplicación real, que tiene sesiones, estado y reglas de negocio que un conjunto de pruebas no tiene.
DAST automatizado frente al pentesting manual
La automatización cubre amplitud; las personas cubren los casos que necesitan una hipótesis. La Developer Guide de OWASP plantea la misma división en su página sobre herramientas DAST: “The testing process can be carried out manually or be automated”. Y añade que “usually business logic errors, race condition checks, and certain zero-day vulnerabilities can only be identified using manual assessments”.
La diferencia aparece al nivel del payload. Un escáner envía una librería de patrones conocidos; un filtro que rechaza esos patrones devuelve un resultado limpio que no es una aplicación limpia. Jonathan Armas, security analyst de Fluid Attacks, describe ese modo de falla en un recorrido por el bypass manual de filtros de inyección SQL:
“When the developers use blacklist filtering, as in the examples above, there is a risk of missing some parameter that can allow the injection”.
(Cuando los desarrolladores utilizan el filtrado por listas negras, como en los ejemplos anteriores, existe el riesgo de omitir algún parámetro que pueda permitir la inyección.)
Encontrar ese parámetro olvidado implica leer el comportamiento del filtro y construirle un payload. Tres cosas que configura un pentester y que DAST no infiere: usuarios de prueba para cada rol, el significado de negocio de una transacción y una cadena de hallazgos de severidad baja que juntos producen uno de severidad alta.
DAST, SAST y SCA no son alternativas
Las tres técnicas miran artefactos distintos en momentos distintos. Correr una y dar la aplicación por probada es el error más común en este terreno.
DAST | SAST | SCA | |
|---|---|---|---|
Qué examina | La aplicación en ejecución | Código fuente, bytecode o binarios | Componentes de terceros |
Necesita código fuente | No | Sí | Manifiestos y lockfiles |
Necesita la app corriendo | Sí | No | No |
Corre desde | El entorno de pruebas en adelante | El primer commit en adelante | El primer commit en adelante |
Señala una línea de código | No | Sí | En la declaración de la dependencia |
Encuentra problemas de configuración y despliegue | Sí | Limitado | No |
Encuentra CVE conocidas en dependencias | Rara vez | No | Sí |
Las Pruebas Estáticas de Seguridad de Aplicaciones (SAST) y el Análisis de Composición de Software (SCA) corren antes y señalan líneas; DAST corre después y prueba comportamiento. La Revisión de Código seguro y la Ingeniería Inversa suman la lectura manual que ninguna técnica automatizada hace. Fluid Attacks ofrece SAST, SCA, SCR y RE como una solución integral. Lee más sobre cómo se combinan, o lanza el demo interactivo.
Cómo correr DAST en un pipeline de CI/CD
Empieza por nombrar los objetivos. Lista cada URL bajo dast.urls, dale a cada una su environment_id si llevas los entornos por separado, y pon strict_connectivity: true para que un endpoint inalcanzable haga fallar el trabajo en vez de devolver un resultado vacío.
Luego decide qué hace el pipeline con los hallazgos. Apunta output.format a SARIF o CSV y publica el archivo como artefacto del workflow, porque la pestaña Security de GitHub no acepta resultados de DAST. Define una política de CI Gate que rompa el build con las severidades que no estás dispuesto a desplegar, y mantenla lo bastante estrecha como para que los desarrolladores no aprendan a esquivarla.
Por último, cierra el ciclo. Solicita un reattack después de cada corrección y da una vulnerabilidad por resuelta solo cuando la nueva prueba lo confirme.
Corre escaneos completos contra un entorno de staging que refleje producción, y mantén los escaneos de producción acotados y programados. Un escaneo agresivo contra un flujo transaccional vivo es una conversación que hay que tener con el dueño de la aplicación antes de la primera corrida, no después.
Conclusiones
DAST se gana su lugar probando lo que los usuarios realmente alcanzan: una aplicación en ejecución, con su configuración, sus cabeceras, su transporte y sus endpoints expuestos. La evidencia que produce es reproducible, y por eso estos hallazgos suelen corregirse rápido.
Sus límites son igual de concretos. DAST no lee código, no alcanza lo que no puede descubrir y, en la implementación de Fluid Attacks, no prueba endpoints autenticados ni especificaciones de API. El State of Attacks 2026 pone la consecuencia en cifras: las herramientas automatizadas encontraron el 88,4 % de las vulnerabilidades y el 55,8 % de la exposición al riesgo, mientras que el 87 % de los problemas de severidad crítica vino de revisión manual. Trata el escaneo como la capa que despeja el terreno rápido, y planea las pruebas que cubren lo que deja en pie.
Preguntas frecuentes
¿DAST necesita acceso al código fuente?
No. DAST es una técnica de caja negra que prueba una aplicación en ejecución desde afuera. Envía peticiones a endpoints vivos y analiza las respuestas, lo que la hace independiente del lenguaje y utilizable contra software que no escribiste. El costo: el hallazgo describe un comportamiento inseguro sin identificar la línea de código responsable.
¿DAST puede probar APIs autenticadas?
Depende de la herramienta. El escáner automatizado de Fluid Attacks cubre endpoints HTTP no autenticados, registros DNS, cabeceras, contenido HTML, conexiones SSL, webhooks y WebSockets. Los endpoints HTTP autenticados y las especificaciones REST, SOAP, GraphQL, gRPC, OpenAPI, Swagger y Postman las cubre PTaaS, donde los pentesters se autentican en la aplicación y siguen las especificaciones de API. Un binario aparte, dast_api, escanea endpoints declarados en una colección de Postman, y el DAST automatizado para APIs figura como trabajo en curso en el roadmap. Ninguna de las dos técnicas soporta DOM APIs.
¿Cómo se mide la precisión de DAST?
Con cuatro números: verdaderos positivos, falsos positivos, falsos negativos y cobertura. Una comparación reproducible necesita un conjunto de pruebas fijo, como el OWASP Benchmark Project, corrido contra cada herramienta y con los dos scorecards publicados. Los conjuntos sintéticos tienen techo: en el benchmark de Fluid Attacks contra una aplicación real con 1.201 vulnerabilidades, el mejor evaluador automatizado alcanzó 22,7 % de recall y 8,8 % de la exposición total al riesgo, mientras que un pentester alcanzó 89,6 % de recall con 100 % de precisión. En esa misma aplicación, el 73,2 % de las vulnerabilidades requería autenticación para ser alcanzada.
¿Es seguro correr DAST contra una aplicación en producción?
Normalmente sí, con control del alcance. Define las URLs exactas que se analizan, excluye operaciones destructivas y programa los escaneos intensivos fuera de las horas pico. Activa strict_connectivity para que un objetivo inalcanzable falle de forma visible en vez de devolver un resultado vacío. Las pruebas de intensidad completa van en un entorno de staging que refleje producción.
¿El escáner DAST de Fluid Attacks reemplaza a un pentester?
No, y los datos de la propia compañía son la razón. En el State of Attacks 2026, el 87 % de las vulnerabilidades de severidad crítica se identificó mediante revisión manual, y los pentesters detectaron el 90 % de la exposición al riesgo que venía de problemas críticos. El escáner cubre siete superficies de ataque a gran velocidad; PTaaS suma los endpoints autenticados y las especificaciones de API, donde se concentró la debilidad más frecuente del año en aplicaciones.
Encuentra lo que solo aparece con la aplicación en ejecución
Nuestro escáner prueba tus endpoints vivos en cada corrida del pipeline, y nuestros pentesters toman el relevo en las superficies autenticadas y las especificaciones de API que vienen después. Prueba gratuita · Contáctanos.
Empieza ya con la solución de seguridad de aplicaciones de Fluid Attacks
