DAST
Ataca a aplicação em execução como um usuário mal-intencionado faria — sem ver o código.
O que é
(Dynamic Application Security Testing) testa a aplicação em execução, de fora para dentro, em caixa-preta: o scanner envia requisições maliciosas e observa as respostas, como um atacante faria — sem acesso ao código-fonte.
Por operar sobre o sistema real montado, o DAST valida o que o não vê: configuração de servidor, headers HTTP, autenticação, sessão e a interação entre componentes.
Como funciona
- crawling — um spider mapeia endpoints, formulários e parâmetros da aplicação
- fuzzing — cada entrada descoberta recebe payloads de ataque (, , path traversal, SSRF)
- análise de resposta — o scanner verifica se o ataque refletiu, executou ou vazou informação
- checagens passivas — headers ausentes, cookies sem flags, versões expostas
Um ataque na prática
O scanner achou um parâmetro id no crawler. Primeiro passo: o teste clássico de SQL injection — fechar a aspa e inserir uma condição sempre-verdadeira. O que o scanner envia:
GET /users?id=1'%20OR%20'1'='1 HTTP/1.1
Host: loja.exemplo.comO que denuncia a falha
A assinatura do SQLi está na resposta: em vez de um usuário, voltaram todos — a condição injetada virou parte da query. O scanner compara essa resposta com a baseline do parâmetro original e conclui: injetável.
200 OK
[ {"id": 1, "nome": "Ana"}, {"id": 2, "nome": "Beto"},
{"id": 3, "nome": "Caio"}, ... ] <- todos os usuáriosQuando não há eco: injeção cega
Nem sempre a resposta devolve os dados — engines modernos escondem o erro. Para esses casos, o scanner usa injeções cegas e infere pelo comportamento. Um atraso controlado é a evidência:
GET /users?id=1'%20AND%20SLEEP(5)-- HTTP/1.1
com o payload: resposta em 5,2 s
sem o payload: resposta em 0,1 s
=> o banco executou o SLEEP: injetável às cegasOnde entra na pipeline
Depois do deploy em staging ou preview: a pipeline sobe o ambiente e aponta o scanner para ele, falhando em achados críticos. Scans agendados contra produção cobrem o que muda fora do ciclo de release.
Pontos fortes e limitações
- forte: reporta o que é realmente explorável — baixíssimo falso positivo, porque só afirma o que provocou
- forte: agnóstico de linguagem — testa HTTP, não código
- fraco: só enxerga a superfície exposta; código sem rota acessível fica de fora
- fraco: lento e tardio — encontra depois do deploy, quando corrigir já custa
conexões no mapa
atualizado em 14/10/2026 · fontes para aprofundar · reportar erro
em outros domínios
- WAF - observação, shadow e enforcementsecopsacha a falha; o WAF mitiga enquanto ela não é corrigida (patch virtual)
Estude antes
Desbloqueia
teste o que entendeu
Carregando perguntas…