Se você trabalha com segurança de aplicações web, provavelmente já se perguntou: “Por onde começo um teste?” ou “Estou cobrindo tudo que deveria?”

É exatamente para isso que existe o WSTG.

O que é o WSTG?

O WSTG (Web Security Testing Guide) é um guia completo de testes de segurança para aplicações web, mantido pelo OWASP (Open Worldwide Application Security Project), a mesma organização por trás do famoso OWASP Top 10.

Mas não confunda os dois.

Enquanto o OWASP Top 10 é uma lista das vulnerabilidades mais críticas (um retrato do problema), o WSTG é um guia metodológico, ele te diz como testar, passo a passo, com técnicas, ferramentas e casos de teste documentados.

O Top 10 te diz que “Injeção” é um risco grave. O WSTG te ensina como identificar, explorar e documentar uma vulnerabilidade de SQL Injection numa aplicação real.

A versão atual é a WSTG v4.2.

Como o WSTG está organizado?

O guia é dividido em categorias de teste, cada uma cobrindo uma área específica da segurança web. Cada categoria contém múltiplos casos de teste com identificadores únicos (ex: WSTG-AUTH-01).

Aqui estão as principais categorias:

Information Gathering (Coleta de Informações): Antes de atacar, você precisa entender o alvo. Quais tecnologias são usadas? Quais endpoints existem? O que está exposto involuntariamente?

Exemplos: Descobrir que a aplicação usa WordPress 5.2 desatualizado, que o servidor expõe cabeçalhos com versões, ou que há um painel admin acessível publicamente.

Configuration & Deployment Management Testing: As configurações estão seguras? O servidor está bem configurado?

Exemplos: TLS fraco, métodos HTTP desnecessários habilitados (como PUT e DELETE), arquivos de backup expostos (.bak, .old), ou listagem de diretórios ativa.

Authentication Testing: Os mecanismos de autenticação são eficazes?

Exemplos: Ausência de bloqueio após tentativas falhas (brute force), senhas padrão ativas, fluxo de recuperação de senha inseguro, ou autenticação multifator (MFA) mal implementada.

Authorization Testing: Após autenticar, o usuário acessa apenas o que deveria?

Exemplos: Um usuário comum conseguir acessar funcionalidades de admin trocando um parâmetro na URL, isso é IDOR (Insecure Direct Object Reference), um dos favoritos dos atacantes.

Session Management Testing: Como a sessão do usuário é gerenciada após o login?

Exemplos: Tokens de sessão previsíveis, cookies sem os atributos HttpOnly ou Secure, ou sessão que nunca expira mesmo após logout.

Input Validation Testing: A aplicação processa entradas do usuário de forma segura?

Exemplos: XSS, SQL Injection, XXE, SSTI (Server-Side Template Injection), Command Injection. Esta é, historicamente, a categoria mais extensa e não é coincidência.

Business Logic Testing: A lógica de negócio pode ser manipulada?

Exemplos: Pular a etapa de pagamento num e-commerce, aplicar um cupom de desconto infinitas vezes, ou acessar o pedido de outro cliente alterando um ID.

Client-Side Testing: O código que roda no navegador do usuário é seguro?

Exemplos: DOM-based XSS, postMessage inseguro, dados sensíveis armazenados no localStorage sem proteção.

WSTG vs OWASP Top 10: qual a diferença?

Essa confusão é muito comum. Veja uma comparação direta:

Em resumo: o Top 10 te diz o que temer. O WSTG te diz como encontrar.

Como usar o WSTG na prática?

O WSTG não foi criado para ser lido do início ao fim como um livro. Ele funciona como uma referência estruturada durante um pentest ou revisão de segurança.

Na prática, um uso comum é:

1. Defina o escopo: Que tipo de aplicação você está testando? E-commerce? API REST? Aplicação bancária? Isso vai guiar quais categorias são mais relevantes.

2. Use os IDs como checklist: Cada teste tem um identificador único. Por exemplo, WSTG-AUTHN-03 cobre testes de bloqueio de conta. Isso facilita rastrear o que foi testado e documentar os achados.

3. Siga as técnicas sugeridas: Cada caso de teste descreve os objetivos, como testar manualmente, ferramentas recomendadas e o que caracteriza uma falha.

4. Documente com os IDs: Nos relatórios de pentest, referenciar os IDs do WSTG adiciona credibilidade e padronização. Seu cliente (ou equipe) pode consultar exatamente o que foi testado e por quê.

Pense no WSTG como um mapa. Você não precisa percorrer cada estrada, mas ter o mapa garante que você não ignora caminhos importantes.

Por que usar o WSTG e não só seguir o instinto?

Pentesters experientes têm intuição afiada. Mas intuição sem estrutura cria pontos cegos.

O WSTG existe para garantir cobertura, consistência e comunicação:

• Cobertura: você não vai esquecer de testar gerenciamento de sessão porque estava focado demais em Input Validation.

• Consistência: dois pentesters diferentes, seguindo o WSTG, vão cobrir os mesmos pontos críticos.

• Comunicação: um relatório referenciando WSTG-SESS-07 fala a mesma língua com qualquer profissional de segurança do mundo.

E para quem está começando, o WSTG é ainda mais valioso: ele estrutura o aprendizado de forma progressiva, do reconhecimento até os testes mais complexos de lógica de negócio.

Se você quer consultar o guia diretamente: https://owasp.org/www-project-web-security-testing-guide/

Um bom teste de segurança não é apenas sobre encontrar vulnerabilidades. É sobre garantir que você procurou nos lugares certos.