DAST (Dynamic Application Security Testing).

Ferramentas DAST interagem com uma aplicação implantada — normalmente via HTTP — sem precisar de código-fonte. Elas exploram endpoints, enviam requisições maliciosas e observam respostas para detectar SQL injection, XSS, SSRF, falhas de autenticação, CORS mal configurado ou cookies inseguros. Como veem o que um atacante veria, complementam o SAST capturando problemas que só aparecem em runtime, inclusive os causados por configuração, infraestrutura ou serviços de terceiros. Em geral rodam em ambientes de staging ou QA e são integrados ao CI/CD como portão de liberação. Ferramentas comuns: OWASP ZAP, Burp Suite, Invicti, Acunetix e StackHawk.

Como funciona

Uma varredura DAST decorre em duas fases. Primeiro, um crawler (spider) mapeia a superfície de ataque da aplicação seguindo links, analisando JavaScript e reproduzindo tráfego gravado para descobrir formulários, parâmetros e rotas de API. Segundo, um scanner ativo modifica cada entrada com payloads de ataque e infere vulnerabilidades a partir de códigos de resposta, temporizações, conteúdo refletido ou assinaturas de erro — por exemplo, uma injeção SQL cega baseada em tempo confirma-se quando um payload SLEEP() atrasa a resposta de forma mensurável.

O DAST moderno evoluiu para varreduras API-first e autenticadas: as aplicações de página única e os back-ends REST/GraphQL expõem pouco a um crawler ingénuo, pelo que os scanners consomem especificações OpenAPI/Swagger e usam sequências de login programadas para alcançar funcionalidades protegidas. A cobertura é habitualmente mapeada contra o OWASP Web Security Testing Guide (WSTG). Os limites do DAST importam tanto quanto: não indica a localização na linha de código, não vê caminhos de código inacessíveis e corre o risco de falsos negativos em estados complexos do lado do cliente — razão pela qual as equipas o combinam com SAST e IAST em vez de dependerem apenas dele. Para evitar varrer produção e desencadear efeitos secundários reais (enviar e-mails, criar encomendas), as varreduras são restringidas a alvos fora de produção e recebem um âmbito definido e uma lista de exclusões.

flowchart LR
  A[Aplicação em execução<br/>staging/QA] --> B[Crawler / spider<br/>mapeia endpoints]
  B --> C[Scanner ativo<br/>injeta payloads]
  C --> D{Anomalia na<br/>resposta?}
  D -->|Sim| E[Reportar achado<br/>SQLi / XSS / SSRF]
  D -->|Não| F[Marcar endpoint como limpo]
  E --> G[Portão CI/CD<br/>falhar build / triagem]