Tutorial: Como testar a segurança de sua aplicação (OWASP)

Toda aplicação que eu coloco no ar passa por um ritual antes de ir para produção: subo um container do OWASP ZAP, aponto o spider para a aplicação e deixo ele mapear tudo que existe do lado de fora. Não é pentest. É higiene básica, o equivalente a rodar npm audit antes do deploy, só que na superfície HTTP.

Antes de mostrar os comandos, vale entender o que é OWASP, quais são as dez ameaças que ela cataloga e como um spider funciona de verdade. Sem isso, você acaba rodando uma ferramenta que cospe um relatório que você não sabe ler.

O que é OWASP

OWASP é a sigla de Open Worldwide Application Security Project, uma fundação sem fins lucrativos criada em 2001 que produz material de segurança de aplicações de forma aberta e gratuita. Não vende produto, não certifica ninguém, não tem dono comercial. Tudo que ela publica é comunitário e aberto.

Na prática, três coisas saem da OWASP e valem para qualquer desenvolvedor:

• Documentos de referência, sendo o Top 10 o mais conhecido, além do ASVS (padrão de verificação de segurança) e dos Cheat Sheets, que são guias curtos e diretos por tema.
• Ferramentas, principalmente o ZAP (o scanner que este artigo usa) e o Dependency-Track.
• Aplicações de treino, como o Juice Shop, feitas para serem vulneráveis de propósito e servirem de campo de tiro.

A relevância do Top 10 não é técnica, é política. Ele virou linguagem comum: aparece em contrato, em questionário de fornecedor, em auditoria PCI-DSS, em requisito de compliance.

O Top 10, edição 2025

A lista é atualizada a cada três ou quatro anos. A oitava edição foi anunciada em novembro de 2025 e finalizada em janeiro de 2026. Se você conhece a lista de 2021 (e a maioria dos tutoriais na internet ainda ensina essa), ela mudou.

Duas categorias novas entraram, uma foi absorvida e várias mudaram de posição.

A01, Broken Access Control. Usuário consegue fazer ou ver o que não deveria. IDOR (trocar /pedido/123 por /pedido/124 e ver o pedido de outra pessoa), escalada de privilégio, endpoint administrativo sem checagem de papel. Continua em primeiro lugar pela quarta edição seguida, e agora absorveu o SSRF, que era categoria separada em 2021.

A02, Security Misconfiguration. Subiu de quinto para segundo. Header de segurança ausente, bucket público, painel de admin com senha padrão, mensagem de erro devolvendo stack trace, diretório listável. Subiu porque cada vez mais o comportamento da aplicação vive em arquivo de configuração, não em código.

A03, Software Supply Chain Failures. Categoria nova, expansão do antigo “componentes vulneráveis”. Não é só a dependência desatualizada: é o pacote npm sequestrado, o build system comprometido, a action de CI que exfiltra secret. A categoria com menor incidência nos dados e maior impacto médio quando acontece.

A04, Cryptographic Failures. Caiu de segundo para quarto. Senha guardada em MD5, dado sensível trafegando em texto claro, chave hardcoded no repositório, TLS mal configurado.

A05, Injection. Caiu de terceiro para quinto, o que não significa que sumiu. Entrada não confiável interpretada como comando: SQL injection, XSS, command injection, path traversal, SSTI. É a categoria com mais CVEs associados.

A06, Insecure Design. Falha de arquitetura, não de implementação. Fluxo de recuperação de senha que permite tomar conta alheia, ausência de rate limit em operação sensível, regra de negócio que não previu o abuso. Código perfeito para uma ideia errada.

A07, Authentication Failures. Mudou de nome (era “Identification and Authentication Failures”). Brute force sem bloqueio, sessão que não expira, token previsível, MFA que dá para pular.

A08, Software or Data Integrity Failures. Confiar em artefato sem verificar. Deserialização insegura, atualização automática sem assinatura, script de CDN sem integrity check.

A09, Security Logging & Alerting Failures. Também mudou de nome, de “Monitoring” para “Alerting”, e a mudança é o recado: log excelente sem alerta não serve para nada. Se você foi invadido há três meses e só descobre agora, é isso.

A10, Mishandling of Exceptional Conditions. Categoria nova. Tratamento errado de situação anormal: erro engolido, sistema que falha aberto em vez de fechado, condição de corrida, exceção que vaza detalhe interno. Reúne 24 CWEs que antes ficavam espalhados.

Repare em uma coisa: nem todas essas categorias são testáveis por ferramenta. A06 e A09, por natureza, não são. Guarde isso, porque no fim do artigo eu volto nesse ponto.

O que é o ZAP

O ZAP (Zed Attack Proxy) é o scanner de segurança web da OWASP. Ele funciona como um proxy interceptador: todo o tráfego entre um cliente e a aplicação passa por ele, que registra, analisa e, quando você manda, modifica e reenvia.

A partir desse proxy, ele oferece três coisas:

1. Spider, que descobre o que existe na aplicação.
2. Scanner passivo, que apenas observa o tráfego e aponta problemas sem tocar em nada.
3. Scanner ativo, que pega o que o spider descobriu e ataca de verdade, injetando payloads.

A ordem importa. O scanner ativo só consegue testar o que o spider encontrou. Um crawl ruim significa um scan ruim, por melhor que seja o resto da ferramenta.

O spider, em detalhe

Spider (ou crawler) é o componente que descobre a superfície de ataque. Ele começa em uma URL semente, busca a página, extrai tudo que parece um caminho para outro lugar e repete o processo em cada descoberta, até acabar ou até estourar o limite que você definiu.

Concretamente, ele procura por:

• href de tags;
• src;
• action, junto com todos os campos dentro dele;
• URLs dentro de arquivos JavaScript e CSS;
• robots.txt e sitemap.xml, que são presentes de mão beijada;
• redirecionamentos e headers como Location.

O produto final não é uma lista de vulnerabilidades. É uma árvore de sites: cada URL encontrada, cada método HTTP aceito, cada parâmetro de query, cada campo de formulário. Isso é o insumo do scanner ativo. Se o spider descobriu GET /produto?id=5, o scanner ativo sabe que existe um parâmetro id para atacar. Se não descobriu, esse parâmetro simplesmente não existe para a ferramenta.

Os dois spiders

Aqui está o ponto que a maioria dos tutoriais pula. O ZAP tem dois spiders, e eles não são intercambiáveis.

Spider tradicional. Baixa o HTML cru, faz parse, extrai os links e segue. Rápido (centenas de URLs por minuto), barato, previsível. E completamente cego para qualquer coisa que dependa de JavaScript, porque ele nunca executa JavaScript. Ele lê o HTML que o servidor mandou, não o DOM que o navegador construiu.

AJAX Spider. Dirige um navegador headless de verdade (Firefox ou Chrome via Selenium). Carrega a página, espera o JavaScript rodar, clica em elementos clicáveis, observa o DOM mudar e registra as requisições XHR que aparecem. Lento, pesado em memória, e a única opção que funciona em SPA.

Se seu front é React, Vue ou Angular, o HTML inicial é praticamente uma div vazia. O spider tradicional vai descobrir a rota / e mais nada. Já vi gente concluir “o scan não achou nada, estamos seguros” a partir de um crawl que nunca saiu da tela de carregamento.

Tipo de appSpiderServer-side rendering (Rails, Django, PHP, Next SSR)Tradicional já cobre bemSPA / front desacopladoAJAX spider obrigatórioAPI REST/GraphQL puraNenhum dos dois, importe o OpenAPI

Na prática, rode os dois em sequência. O tradicional é barato e pega o esqueleto, o AJAX complementa com o que só existe depois do JavaScript.

O que o spider não faz

• Não adivinha. Um endpoint sem nenhum link apontando para ele não vai ser encontrado. Para isso existe brute force de diretório (o add-on Forced Browse do ZAP, ou ferramentas como ffuf), que é técnica diferente.
• Não entende regra de negócio. Ele preenche formulário com dados sintéticos. Um fluxo de checkout em três etapas com validação em cada uma provavelmente trava na primeira.
• Não sabe o que é destrutivo. Se existe GET /admin/delete/42, ele vai clicar. Por isso ambiente descartável.
• Não mantém sessão sozinho. Sem configuração de autenticação, ele testa só a área pública.

Por que rodar em Docker

O ZAP é uma aplicação Java com dezenas de add-ons. Instalar na máquina significa gerenciar JDK, plugins e um diretório de configuração que cresce sem parar. Em container:

• ambiente descartável, cada scan começa limpo;
• versão fixada, então o resultado de hoje é reproduzível amanhã;
• a mesma linha de comando roda em qualquer máquina;
• fácil isolar em uma rede Docker junto com o alvo, sem expor nada.

A imagem oficial mudou de casa. A antiga owasp/zap2docker-stable está deprecada. Use:

docker pull ghcr.io/zaproxy/zaproxy:stable

O tutorial é longo. Completo em: https://adourado.substack.com/p/tutorial-como-testar-a-seguranca