Dynamic Application Security Testing (DAST)

O que é DAST?

DAST é uma técnica de testes de segurança de caixa-preta: avalia uma aplicação enquanto essa aplicação está em execução, sem ver o código-fonte por trás dela. Como trabalha de fora, é independente de linguagem e funciona igual contra o código que você escreveu e o que você comprou.

Um escaneamento tem quatro etapas: mapeia e rastreia o alvo para encontrar páginas, parâmetros e endpoints; envia payloads de ataque às entradas que encontrou; lê as respostas em busca de erros, conteúdo inesperado, mudanças de tempo ou acessos não autorizados; e reporta o que confirmou, com a requisição e a resposta como evidência.

O que DAST não é

Não é um leitor de código. Um achado de DAST diz que uma aplicação se comporta de forma insegura, não qual linha produziu esse comportamento. Essa limitação é estrutural, não uma lacuna do produto, e tem consequências concretas nas ferramentas: mais abaixo está o problema da aba Security do GitHub.

Também não é exaustivo. Um scanner só testa o que alcança: as rotas atrás de um login, os caminhos de código que um rastreador nunca dispara e os fluxos que dependem do estado do negócio ficam sem teste, a menos que outra coisa os cubra. A documentação da Fluid Attacks indica que nem o scanner nem os pentesters suportam DOM APIs.

Por que DAST importa

As vulnerabilidades em execução são as que uma base de código correta ainda pode carregar. A configuração do deploy, os ajustes de TLS, os cabeçalhos de resposta, o gerenciamento de sessões e as integrações com terceiros não têm uma linha de código para inspecionar, e só existem quando a aplicação está no ar.

A configuração falha onde não existe código-fonte

Duas regras de detecção da Fluid Attacks mostram isso. A DAST-SCNRY reporta uma vulnerabilidade “when the Content-Security-Policy header is completely missing from the HTTP response”. A DAST-TNTER lê o valor da CSP e sinaliza uma diretiva script-src ausente ou configurações inseguras como unsafe-inline ou unsafe-eval. As duas são classificadas como WEB DAST, com HTTP como alvo e HEADERS como tecnologia.

Nenhum dos dois achados existe no repositório. Eles existem na resposta.

Volume não é risco

As ferramentas automatizadas encontram a maior parte dos problemas e uma parcela menor do perigo. No State of Attacks 2026, as ferramentas automatizadas da Fluid Attacks identificaram 88,4 % de todas as vulnerabilidades reportadas, mas 55,8 % da exposição total ao risco; os testes manuais responderam pelos 11,6 % restantes das vulnerabilidades e por 44,2 % da exposição. Entre as vulnerabilidades de severidade crítica, 87 % foram identificadas por revisão manual. Isso é uma divisão de trabalho, não um veredito sobre as ferramentas: um scanner limpa o terreno rápido, e não é ele que encontra o problema que termina no relatório de incidente.

As aplicações são o alvo que as equipes corrigem mais rápido

O mesmo relatório conta 140.551 vulnerabilidades no alvo “Application”, com 3.903.585,51 CVSSF de exposição ao risco, e as aplicações foram o alvo mais rápido de remediar: pelo menos 40 % de suas vulnerabilidades foram corrigidas em 30 dias. Achados que chegam com uma requisição reproduzível tendem a andar, porque um desenvolvedor consegue repeti-los.

DAST na Fluid Attacks

A Fluid Attacks executa o Dynamic Application Security Testing como um scanner automatizado e o Pentesting as a Service (PTaaS) como testes manuais. A documentação coloca a divisão em duas frases: “DAST is an automated scanner. In PTaaS, pentesters test applications manually”. O que segue é quais superfícies cada um alcança, como o escaneamento é configurado e os dois pontos em que ele para.

O que o scanner alcança e onde o pentester assume

O scanner alcança sete superfícies; oito outras precisam de um pentester.

Fonte: superfícies de ataque suportadas da Fluid Attacks. O PTaaS está disponível exclusivamente no plano Advanced.

A resposta honesta para “o DAST pode testar APIs?” depende de qual ferramenta você quer dizer. O scanner web é distribuído como o contêiner Docker fluidattacks/dast e cobre as sete superfícies acima. Uma ferramenta separada, dast_api, é distribuída como binário e “scans API endpoints declared in a Postman collection”. O roadmap da Fluid Attacks lista o DAST automatizado para APIs como trabalho em andamento, então, até que ele saia, as especificações de API são cobertas pelos pentesters.

Como isso funciona na prática

Ative o strict_connectivity. Sem ele, um escaneamento que nunca alcançou o alvo volta limpo, e isso se lê exatamente como um escaneamento que não encontrou nada.

Por que os achados de DAST não cabem na aba Security do GitHub

A documentação da Fluid Attacks é direta: “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”. Em vez disso, configure output.format: SARIF ou CSV e leia a saída do scanner como artefato do workflow. Vale saber antes de desenhar um painel em torno de uma aba que vai ficar vazia.

A autenticação é onde o scanner passa o bastão

A ausência ou evasão de autenticação lidera, com 855,99 de exposição média.

Fonte: State of Attacks 2026 da Fluid Attacks, cobrindo de 1º de janeiro a 31 de dezembro de 2025.

Coloque os dois fatos lado a lado. O DAST automatizado testa endpoints HTTP não autenticados. A fraqueza que lidera o alvo Application é a ausência ou evasão do mecanismo de autenticação. O scanner confirma que um recurso protegido está de fato protegido de um visitante anônimo; ele não faz login como dois usuários diferentes para verificar se um consegue ler os registros do outro, que é o que a referência insegura a objetos exige.

O benchmark coloca um número nessa mesma lacuna. Das 1.201 vulnerabilidades semeadas naquela aplicação de teste, 73,2 % exigiam autenticação para serem alcançadas.

É por isso que o PTaaS existe como uma oferta separada, e não como um nível premium do mesmo escaneamento.

Verificar a correção faz parte do teste

Um relatório não é um resultado. A documentação da Fluid Attacks diz sem rodeios: “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”. O Reattack faz isso quando solicitado, e a prática ao redor move mais o ponteiro do que o escaneamento: os sistemas que usam o CI Gate alcançaram uma taxa de remediação de 72,2 %, contra 58 % dos sistemas sem ele.

Para aprofundar: pentesting as a service.

O que um escaneamento DAST alcança e o que escapa

Um escaneamento confirma uma vulnerabilidade de duas maneiras. Os testes in-band leem a resposta na própria requisição; os testes out-of-band esperam o servidor fazer a chamada.

O que a regra examina e quando ela reporta um achado.

A confirmação in-band cobre quase toda essa lista, e falha com as vulnerabilidades cegas: uma falsificação de requisição do lado do servidor ou uma injeção de comandos que não devolve nada ao cliente não deixa evidência no corpo da resposta. O DAST out-of-band fecha essa lacuna com um payload que faz o alvo abrir uma conexão com um receptor controlado por quem testa. Os pentesters da Fluid Attacks usam o Interactsh, “an open-source tool that finds vulnerabilities that cause out-of-band (OOB) interactions”.

In-band confirma na resposta; out-of-band, em uma chamada separada. Elaboração própria.

DAST para APIs

Os testes de segurança de APIs são onde a maioria das explicações introdutórias fica vaga, então aqui vai a versão precisa. Um serviço REST ou GraphQL expõe operações descritas em uma especificação, não links que um rastreador possa seguir, então o DAST só as alcança se receber essa especificação: uma coleção do Postman, um documento OpenAPI ou uma consulta de introspecção.

Os riscos que importam ali são riscos de autorização. O OWASP API Security Top 10 (2023) abre com API1:2023 Broken Object Level Authorization e também lista API2:2023 Broken Authentication e API5:2023 Broken Function Level Authorization. Testar qualquer um deles significa manter pelo menos duas identidades autenticadas e verificar o que cada uma alcança: um passo de configuração, não um payload.

O vazamento da Panera Bread em 2018 mostra o que acontece quando ninguém faz esse teste. Segundo reportagem do Krebs on Security, os registros de clientes ficavam no site da empresa em texto simples e sem controle de acesso, e os identificadores de conta eram inteiros sequenciais, então qualquer pessoa podia percorrê-los um a um. A falha foi reportada em 2 de agosto de 2017 e continuava ativa quando a matéria foi publicada em 2 de abril de 2018: oito meses. Krebs escreveu que os números incrementais de clientes sugeriam que a cifra “may be higher than seven million”, e uma atualização posterior a situou em um número que “appears to exceed 37 million”.

Esse caso corta nos dois sentidos. Um endpoint não autenticado servindo dados de clientes está plenamente dentro do que o DAST alcança. A mesma falha um login mais adentro não estaria.

Qual é a precisão do DAST?

A precisão do DAST são quatro números, não um adjetivo: verdadeiros positivos, falsos positivos, falsos negativos e a parcela da aplicação efetivamente coberta. Uma promessa de “poucos falsos positivos” não diz nada sobre o terceiro nem sobre o quarto.

A forma reproduzível de comparar ferramentas é um conjunto de testes fixo e deliberadamente vulnerável. O OWASP Benchmark Project é “a Java and Python test suite designed to verify the speed and accuracy of vulnerability detection tools”, analisável por ferramentas estáticas, dinâmicas e interativas, e cada vulnerabilidade que ele pontua é explorável. Rodar dois scanners contra o mesmo conjunto e publicar os dois scorecards é evidência; uma página de marketing não é.

Conjuntos sintéticos têm seu próprio teto, e a lacuna aparece nos números da Fluid Attacks. Em seu benchmark de 36 ferramentas AppSec de terceiros contra uma aplicação com 1.201 vulnerabilidades em 105 categorias CWE e 461.500 CVSSF, um pentester encontrou 1.076 delas: 89,6 % de recall com 100 % de precisão. O melhor avaliador automatizado foi a própria ferramenta da Fluid Attacks, que cobre SAST, SCA e DAST ao mesmo tempo, com 22,7 % de recall e 8,8 % da exposição total ao risco. Entre as outras 34 ferramentas, o recall médio foi de 1,7 %.

Um scanner com pontuação perfeita em um benchmark ainda vai perder a maior parte de uma aplicação real, que tem sessões, estado e regras de negócio que um conjunto de testes não tem.

DAST automatizado frente ao pentesting manual

A automação cobre amplitude; as pessoas cobrem os casos que exigem uma hipótese. O Developer Guide da OWASP faz a mesma divisão em sua página sobre ferramentas DAST: “The testing process can be carried out manually or be automated”. E acrescenta que “usually business logic errors, race condition checks, and certain zero-day vulnerabilities can only be identified using manual assessments”.

A diferença aparece no nível do payload. Um scanner envia uma biblioteca de padrões conhecidos; um filtro que rejeita esses padrões devolve um resultado limpo que não é uma aplicação limpa. Jonathan Armas, security analyst da Fluid Attacks, descreve esse modo de falha em um passo a passo de bypass manual de filtros de injeção 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”.

(Quando os desenvolvedores usam a filtragem por lista negra, como nos exemplos acima, existe o risco de omitir algum parâmetro que possa permitir a injeção).

Encontrar esse parâmetro esquecido significa ler o comportamento do filtro e construir um payload para ele. Três coisas que um pentester configura e que o DAST não infere: usuários de teste para cada papel, o significado de negócio de uma transação e uma cadeia de achados de severidade baixa que juntos produzem um de severidade alta.

DAST, SAST e SCA não são alternativas

As três técnicas olham artefatos diferentes em momentos diferentes. Rodar uma e dar a aplicação por testada é o erro mais comum nesse terreno.

Os Testes Estáticos de Segurança de Aplicações (SAST) e a Análise de Composição de Software (SCA) rodam antes e apontam linhas; o DAST roda depois e prova comportamento. A Revisão de Código Seguro e a Engenharia Reversa somam a leitura manual que nenhuma técnica automatizada faz. A Fluid Attacks oferece SAST, SCA, SCR e RE como uma solução integral. Leia mais sobre como elas se combinam, ou acesse a demo interativa.

Como rodar DAST em um pipeline de CI/CD

Comece nomeando os alvos. Liste cada URL em dast.urls, dê a cada uma o seu environment_id se você controla os ambientes separadamente, e defina strict_connectivity: true para que um endpoint inalcançável faça o job falhar em vez de devolver um resultado vazio.

Depois decida o que o pipeline faz com os achados. Aponte output.format para SARIF ou CSV e publique o arquivo como artefato do workflow, porque a aba Security do GitHub não aceita resultados de DAST. Defina uma política de CI Gate que quebre o build nas severidades que você não está disposto a implantar, e mantenha-a estreita o bastante para que os desenvolvedores não aprendam a contorná-la.

Por último, feche o ciclo. Solicite um reattack após cada correção e considere uma vulnerabilidade resolvida apenas quando o novo teste confirmar.

Rode escaneamentos completos contra um ambiente de staging que espelhe a produção, e mantenha os escaneamentos de produção delimitados e agendados. Um escaneamento agressivo contra um fluxo transacional ativo é uma conversa para ter com o dono da aplicação antes da primeira execução, não depois.

Conclusões

O DAST ganha seu lugar testando aquilo que os usuários realmente alcançam: uma aplicação em execução, com sua configuração, seus cabeçalhos, seu transporte e seus endpoints expostos. A evidência que ele produz é reproduzível, e por isso esses achados costumam ser corrigidos rápido.

Seus limites são igualmente concretos. O DAST não lê código, não alcança o que não consegue descobrir e, na implementação da Fluid Attacks, não testa endpoints autenticados nem especificações de API. O State of Attacks 2026 coloca a consequência em números: as ferramentas automatizadas encontraram 88,4 % das vulnerabilidades e 55,8 % da exposição ao risco, enquanto 87 % dos problemas de severidade crítica vieram de revisão manual. Trate o escaneamento como a camada que limpa o terreno rápido, e planeje os testes que cobrem o que ele deixa de pé.

Perguntas frequentes

O DAST precisa de acesso ao código-fonte?

Não. O DAST é uma técnica de caixa-preta que testa uma aplicação em execução de fora. Ele envia requisições a endpoints ativos e analisa as respostas, o que o torna independente de linguagem e utilizável contra software que você não escreveu. O custo: o achado descreve um comportamento inseguro sem identificar a linha de código responsável.

O DAST pode testar APIs autenticadas?

Depende da ferramenta. O scanner automatizado da Fluid Attacks cobre endpoints HTTP não autenticados, registros DNS, cabeçalhos, conteúdo HTML, conexões SSL, webhooks e WebSockets. Os endpoints HTTP autenticados e as especificações REST, SOAP, GraphQL, gRPC, OpenAPI, Swagger e Postman são cobertos pelo PTaaS, onde os pentesters se autenticam na aplicação e seguem as especificações de API. Um binário separado, dast_api, escaneia endpoints declarados em uma coleção do Postman, e o DAST automatizado para APIs consta como trabalho em andamento no roadmap. Nenhuma das duas técnicas suporta DOM APIs.

Como se mede a precisão do DAST?

Com quatro números: verdadeiros positivos, falsos positivos, falsos negativos e cobertura. Uma comparação reproduzível precisa de um conjunto de testes fixo, como o OWASP Benchmark Project, rodado contra cada ferramenta e com os dois scorecards publicados. Conjuntos sintéticos têm teto: no benchmark da Fluid Attacks contra uma aplicação real com 1.201 vulnerabilidades, o melhor avaliador automatizado alcançou 22,7 % de recall e 8,8 % da exposição total ao risco, enquanto um pentester alcançou 89,6 % de recall com 100 % de precisão. Nessa mesma aplicação, 73,2 % das vulnerabilidades exigiam autenticação para serem alcançadas.

É seguro rodar DAST contra uma aplicação em produção?

Normalmente sim, com controle de escopo. Defina as URLs exatas a analisar, exclua operações destrutivas e agende os escaneamentos intensivos fora dos horários de pico. Ative o strict_connectivity para que um alvo inalcançável falhe de forma visível em vez de devolver um resultado vazio. Os testes de intensidade total ficam em um ambiente de staging que espelhe a produção.

O scanner DAST da Fluid Attacks substitui um pentester?

Não, e os dados da própria empresa são a razão. No State of Attacks 2026, 87 % das vulnerabilidades de severidade crítica foram identificadas por revisão manual, e os pentesters detectaram 90 % da exposição ao risco vinda de problemas críticos. O scanner cobre sete superfícies de ataque em alta velocidade; o PTaaS soma os endpoints autenticados e as especificações de API, onde se concentrou a fraqueza mais frequente do ano em aplicações.

Encontre o que só aparece com a aplicação em execução

Nosso scanner testa seus endpoints ativos a cada execução do pipeline, e nossos pentesters assumem nas superfícies autenticadas e nas especificações de API que vêm depois. Teste gratuito · Fale conosco.