Fundamentos e método
Aprender somente o Linux, HTTP e Burp necessários para testar aplicações. O objetivo não é virar administrador de sistemas: é conseguir observar, repetir e documentar o comportamento de uma aplicação.
S01 Linux mínimo para pentest webMontar um ambiente de estudo e conseguir navegar, buscar, filtrar, baixar, inspecionar e registrar dados pelo terminal sem depender de tutoriais para cada comando. terminal ›
Montar um ambiente de estudo e conseguir navegar, buscar, filtrar, baixar, inspecionar e registrar dados pelo terminal sem depender de tutoriais para cada comando.
Conteúdo que precisa dominar
- Sistema de arquivos, caminhos absolutos e relativos
- Permissões no nível de leitura e execução
- Pipes e redirecionamento
- grep, find, less, head, tail, cut e sort
- curl, wget, jq e openssl no uso cotidiano
- Docker apenas para subir laboratórios
Laboratórios da semana
- Bandit 0–12
- Subir OWASP Juice Shop com Docker e confirmar a porta local
- Fazer uma requisição GET e uma POST com curl
- Formatar uma resposta JSON com jq
Leitura e prática essenciais
- Linux JourneyFaça somente Grasshopper: diretórios, arquivos, permissões, processos e pipes.
- OverTheWire BanditNíveis 0–12; leia o manual dos comandos antes de procurar solução.
- MDN — visão geral de HTTPLeitura em português para conectar terminal e web.
Aprofundamento opcional
- TryHackMe — Web Application PentestingUse os módulos introdutórios de ambiente e fundamentos web; não tente concluir a trilha inteira agora.
- ExplainShellCole comandos que não entendeu e examine cada argumento.
Prática manual
Crie um repositório privado de notas com uma folha de consulta contendo apenas os comandos que você realmente usou. Para cada comando, registre um exemplo real e o resultado esperado.
Entrega de portfólio
`comandos-pentest-web.md` + arquivo `setup.md` explicando como subir e derrubar seu laboratório local.
Você consegue subir o laboratório, encontrar um arquivo, filtrar texto e consultar uma API JSON sem copiar uma sequência pronta.
Não estudar administração Linux, hardening, serviços de rede ou shell scripting avançado nesta fase.
S02 HTTP, navegador e fronteiras de confiançaLer uma transação HTTP completa e explicar quais dados o cliente controla, como o navegador mantém estado e quais controles pertencem ao navegador ou ao servidor. fundamento web ›
Ler uma transação HTTP completa e explicar quais dados o cliente controla, como o navegador mantém estado e quais controles pertencem ao navegador ou ao servidor.
Conteúdo que precisa dominar
- Métodos, status, headers e corpo
- Cookies, atributos Secure, HttpOnly e SameSite
- Sessão, cache e redirecionamentos
- Origin, site, same-origin policy e CORS
- Content-Type e codificação de URL
- TLS no nível necessário para testes web
Laboratórios da semana
- Capturar no DevTools login, logout e renovação de sessão de um app local
- Alterar método, Content-Type, query string e body com curl
- Comparar respostas 200, 302, 401, 403, 404 e 500
- Identificar todos os cookies e atributos de uma sessão
Leitura e prática essenciais
- MDN HTTPMétodos, mensagens, headers, cookies e CORS.
- PortSwigger — HTTP basicsIntrodução prática da Web Security Academy.
- WSTG — Information GatheringLeia o índice para entender o que um testador observa antes de explorar.
Aprofundamento opcional
- TryHackMe — Web Application PentestingFaça a parte de fundamentos HTTP se o conteúdo da MDN ainda estiver abstrato.
- MDN — Same-origin policyUse tradução automática e monte um glossário.
Prática manual
Desenhe o fluxo de uma ação do seu app: navegador → frontend → API → banco/serviço. Marque em vermelho tudo que o usuário consegue alterar antes de a requisição chegar ao servidor.
Entrega de portfólio
Diagrama simples do fluxo HTTP + tabela de cookies, headers e parâmetros controláveis pelo cliente.
Você consegue olhar uma requisição desconhecida e explicar autenticação, estado, formato, origem e possíveis pontos de manipulação.
Não decorar headers. Entenda quem os define, quem confia neles e o que muda quando você os altera.
S03 Burp Suite como ferramenta principalUsar o Burp sem depender do navegador para repetir, comparar e modificar requisições. Burp ›
Usar o Burp sem depender do navegador para repetir, comparar e modificar requisições.
Conteúdo que precisa dominar
- Proxy e histórico HTTP
- Escopo e interceptação seletiva
- Repeater e organização por abas
- Decoder e Comparer
- Intruder Community e limitações
- Match/replace e comentários
- Evidências reproduzíveis
Laboratórios da semana
- Configurar escopo para ignorar domínios externos
- Enviar login e uma chamada autenticada ao Repeater
- Usar Decoder em URL, Base64 e HTML
- Comparar duas respostas de usuários diferentes
- Executar um ataque pequeno no Intruder contra laboratório autorizado
Leitura e prática essenciais
- Burp Suite — Getting startedInstalação, navegador integrado e primeiro fluxo.
- Web Security Academy — Burp SuiteLearning path oficial da ferramenta.
- Burp Community EditionUse a versão gratuita durante a trilha.
Aprofundamento opcional
- TryHackMe — Web Application PentestingUse os módulos de Burp para reforçar o fluxo guiado.
- Burp documentation — RepeaterReferência permanente.
Prática manual
No seu app local, capture uma operação completa de CRUD. Repita sem a interface, altere um campo escondido e remova headers até descobrir quais são realmente necessários.
Entrega de portfólio
Arquivo de projeto do Burp ou capturas organizadas + checklist pessoal de fluxo Proxy → Repeater → evidência.
Você consegue reproduzir uma ação exclusivamente pelo Repeater e produzir uma sequência de passos que outra pessoa consegue repetir.
Não instalar dezenas de extensões. Primeiro domine as ferramentas nativas e mantenha o ambiente previsível.
S04 Metodologia, escopo e primeiro relatórioTransformar exploração solta em um teste autorizado, rastreável e comunicável. ofício ›
Transformar exploração solta em um teste autorizado, rastreável e comunicável.
Conteúdo que precisa dominar
- Escopo, regras de engajamento e limitações
- Hipóteses e casos de teste
- Evidência mínima suficiente
- Passos de reprodução
- Impacto técnico e impacto de negócio
- CWE e introdução ao CVSS
- Reteste e estado do achado
Laboratórios da semana
- Ler cinco relatórios públicos e comparar estruturas
- Classificar três falhas de laboratório com CWE
- Pontuar duas falhas no CVSS v4.0 e justificar cada métrica
- Escrever e retestar um achado no próprio laboratório
Leitura e prática essenciais
- OWASP WSTG — Testing FrameworkUse como estrutura, não como lista para decorar.
- HackerOne — Hacker101Veja exemplos de comunicação e prática web.
- MITRE CWEAprenda a localizar a categoria correta, sem memorizar números.
- FIRST CVSS v4.0 CalculatorUse a versão atual e registre o vetor, não só a nota.
Aprofundamento opcional
- HackerOne HacktivityLeia relatórios divulgados e observe clareza, impacto e evidência.
- OWASP Top 10:2025Documento de conscientização; não substitui metodologia.
Prática manual
Escolha uma falha simples já reproduzida e escreva um relatório com título, resumo, ativo afetado, pré-condições, passos, evidências, impacto, CWE, CVSS, recomendação e reteste.
Entrega de portfólio
Primeiro relatório profissional em Markdown e um template reutilizável de achado.
Um desenvolvedor consegue reproduzir e compreender o risco sem conversar com você, e um gestor entende por que o problema importa.
Não aumentar severidade para chamar atenção. Severidade sem justificativa prejudica credibilidade.
Identidade, autenticação e acesso
Testar quem o usuário é, como mantém a sessão e o que pode acessar. É uma das áreas mais valiosas para Web/API Pentest porque envolve impacto real e muitas falhas de lógica.
S05 Testes de autenticaçãoAvaliar sistematicamente cadastro, login, recuperação e proteção contra tentativas abusivas. login ›
Avaliar sistematicamente cadastro, login, recuperação e proteção contra tentativas abusivas.
Conteúdo que precisa dominar
- Enumeração de usuários
- Política de senha e credenciais padrão
- Brute force, credential stuffing e rate limit
- Recuperação e alteração de senha
- Tokens previsíveis, reutilização e expiração
- Diferenças de resposta e timing
Laboratórios da semana
- 3–5 labs Apprentice/Practitioner de autenticação
- Testar enumeração por mensagem, status, tamanho e tempo
- Observar rate limit por IP, conta, sessão e endpoint
- Mapear o fluxo completo de recuperação de senha
Leitura e prática essenciais
- PortSwigger — AuthenticationTeoria e labs essenciais.
- WSTG — Authentication TestingTransforme o capítulo em checklist.
- OWASP Authentication Cheat SheetLeia principalmente enumeração, reautenticação e recuperação.
Aprofundamento opcional
- TryHackMe — Web Application PentestingFaça os módulos de authentication attacks.
- PortSwigger — Username enumerationAprofundamento de diferenças de resposta e timing.
Prática manual
Monte uma matriz para seu app local: cadastro, login, logout, alterar senha, esqueci a senha, alterar e-mail e exclusão da conta. Liste estados e abusos possíveis.
Entrega de portfólio
Checklist de autenticação preenchido + um relatório de falha ou de controle validado.
Você consegue testar autenticação sem se limitar a “tentar senhas” e consegue demonstrar impacto no fluxo de conta.
Não realizar brute force em alvo real sem permissão explícita e limites definidos no escopo.
S06 Sessões, JWT e OAuth/OIDCEntender como identidade e estado atravessam cookies, tokens e fluxos de autorização, identificando erros de implementação. tokens ›
Entender como identidade e estado atravessam cookies, tokens e fluxos de autorização, identificando erros de implementação.
Conteúdo que precisa dominar
- Fixação, roubo, renovação e invalidação de sessão
- Atributos de cookie e timeout
- JWT: header, claims, assinatura, algoritmo e chaves
- OAuth roles, redirect_uri, state e PKCE
- Diferença entre autenticação e autorização
- Logout e revogação
Laboratórios da semana
- 3 labs de JWT
- 2 labs de OAuth
- Testar invalidação no logout e na troca de senha
- Comparar sessão em dois navegadores e após mudança de privilégio
Leitura e prática essenciais
- WSTG — Session Management TestingBase metodológica.
- PortSwigger — JWT attacksFaça os labs iniciais e de verificação de assinatura.
- PortSwigger — OAuth authenticationEntenda o fluxo antes de explorar.
- OWASP Session Management Cheat SheetReferência para avaliar controles.
Aprofundamento opcional
- TryHackMe — Web Application PentestingUse módulos sobre JWT e autenticação moderna quando disponíveis na trilha.
- OAuth 2.0 Security Best Current PracticeLeitura avançada; foque em ameaças e recomendações.
Prática manual
Desenhe o ciclo de vida do token do seu app: emissão, armazenamento, envio, renovação, revogação e expiração. Teste o que acontece quando cada etapa é manipulada.
Entrega de portfólio
Diagrama do ciclo de sessão/token + relatório de teste com evidências positivas e negativas.
Você consegue explicar por que “JWT assinado” não significa “sessão segura” e identificar onde o servidor deve tomar decisões.
Não focar só em `alg:none`; problemas modernos aparecem em validação de claims, chaves, fluxo e autorização.
S07 Controle de acesso, IDOR e BOLATestar acesso horizontal, vertical e contextual em páginas, funções, objetos e propriedades. #1 prioridade ›
Testar acesso horizontal, vertical e contextual em páginas, funções, objetos e propriedades.
Conteúdo que precisa dominar
- Autorização horizontal e vertical
- IDOR/BOLA em path, query, body e headers
- Controles apenas no frontend
- Métodos alternativos e endpoints esquecidos
- Multi-tenant e troca de contexto
- Matriz usuário × ação × objeto
Laboratórios da semana
- 4–6 labs de access control
- Criar dois usuários e uma conta administrativa no laboratório
- Trocar IDs, UUIDs, tenant IDs e roles em todas as posições
- Testar GET, POST, PUT, PATCH e DELETE separadamente
Leitura e prática essenciais
- PortSwigger — Access controlConclua uma seleção de labs do básico ao intermediário.
- WSTG — Authorization TestingUse como checklist.
- OWASP API1:2023 BOLAConecte web e API.
Aprofundamento opcional
- TryHackMe — Web Application PentestingUse os módulos de access control e IDOR.
- OWASP Authorization Cheat SheetLeia para melhorar recomendações.
Prática manual
Crie uma matriz de autorização do seu app com pelo menos três perfis e dez ações. Execute cada ação com a sessão errada e registre resposta, evidência e impacto.
Entrega de portfólio
Matriz de autorização + relatório de IDOR/BOLA ou evidência de cobertura adequada.
Você testa autorização por ação e objeto, e não considera um botão escondido como controle de segurança.
Não testar apenas IDs sequenciais. UUIDs também precisam de autorização e podem vazar em outras respostas.
S08 MFA e falhas de lógica em fluxos de contaEncontrar formas de pular etapas, reutilizar estados ou combinar funções legítimas para tomar uma conta. lógica ›
Encontrar formas de pular etapas, reutilizar estados ou combinar funções legítimas para tomar uma conta.
Conteúdo que precisa dominar
- Bypass e recuperação de MFA
- Troca de e-mail e telefone
- Convites e vinculação de conta
- Reautenticação para ações sensíveis
- Estados incompletos e passos fora de ordem
- Account linking e identidade federada
Laboratórios da semana
- 2–3 labs de MFA
- 2 labs de lógica relacionados a conta
- Reordenar passos e reutilizar tokens
- Testar navegação direta depois da primeira etapa
Leitura e prática essenciais
- PortSwigger — Authentication: multi-factorLabs focados em bypass de MFA.
- PortSwigger — Business logic vulnerabilitiesLeia metodologia e exemplos de fluxo.
- WSTG — Identity Management TestingCadastro, provisionamento e papéis.
Aprofundamento opcional
- TryHackMe — Web Application PentestingEscolha salas de authentication logic e MFA.
- OWASP Multifactor Authentication Cheat SheetApoio para avaliar recuperação e troca de fator.
Prática manual
Escolha um fluxo com três ou mais passos do seu app. Desenhe uma máquina de estados simples e teste transições não previstas: voltar, pular, repetir, trocar usuário e abrir em outra sessão.
Entrega de portfólio
Diagrama de estados + lista de abuse cases + relatório de uma quebra de fluxo ou conclusão fundamentada.
Você deixa de testar apenas inputs e começa a testar a sequência e as invariantes do processo.
Não confundir “a interface não deixa” com “o servidor não aceita”. Envie as etapas manualmente no Repeater.
Injeções e segurança do navegador
Dominar as classes de falha que surgem quando dados não confiáveis são interpretados como SQL, HTML, comandos, caminhos ou instruções de template.
S09 SQL Injection e NoSQL InjectionIdentificar, confirmar e explorar injeções em consultas sem depender de scanners automáticos. injeção ›
Identificar, confirmar e explorar injeções em consultas sem depender de scanners automáticos.
Conteúdo que precisa dominar
- Contexto de string, número, ORDER BY e LIKE
- UNION, error-based e blind SQLi
- Boolean e time-based
- NoSQL operators e sintaxe JSON
- Limites de impacto e extração mínima
- Diferenciação entre erro e falso positivo
Laboratórios da semana
- 4–6 labs de SQLi incluindo ao menos um blind
- 1–2 labs de NoSQLi
- Confirmar manualmente cada comportamento no Repeater
- Registrar payload, hipótese, resposta e conclusão
Leitura e prática essenciais
- PortSwigger — SQL injectionSeleção progressiva de labs.
- PortSwigger — NoSQL injectionTeoria e labs introdutórios.
- WSTG — Input Validation TestingUse a seção de SQL/NoSQL como referência.
Aprofundamento opcional
- TryHackMe — Web Application PentestingUse módulos de SQLi como reforço guiado.
- OWASP SQL Injection Prevention Cheat SheetPara recomendações precisas sem implementar código.
Prática manual
Em um laboratório local, crie uma tabela de teste por parâmetro: contexto provável, caracteres especiais, mudança observada e técnica de confirmação. Não precisa escrever uma aplicação vulnerável.
Entrega de portfólio
Caderno de testes de injeção + um relatório completo com extração mínima necessária para provar impacto.
Você consegue distinguir erro de aplicação, filtro, WAF e injeção real usando respostas controladas.
Não extrair dados além do necessário em alvo autorizado. Prova de impacto deve ser proporcional e segura.
S10 XSS refletido, armazenado e DOMEntender contexto de execução e construir provas de conceito seguras para diferentes tipos de XSS. browser ›
Entender contexto de execução e construir provas de conceito seguras para diferentes tipos de XSS.
Conteúdo que precisa dominar
- HTML, atributo, JavaScript e URL contexts
- Reflected, stored e DOM XSS
- Sources, sinks e DOM clobbering básico
- Encoding e sanitização
- CSP como mitigação adicional
- Impacto real: sessão, ações e dados
Laboratórios da semana
- 5 labs cobrindo reflected, stored e DOM
- Identificar contexto antes de escolher payload
- Demonstrar impacto sem capturar dados reais
- Testar comportamento com e sem CSP quando o lab permitir
Leitura e prática essenciais
- PortSwigger — Cross-site scriptingSelecione labs por contexto e tipo.
- WSTG — Client-side TestingLeia XSS e DOM-based testing.
- OWASP XSS Prevention Cheat SheetUse para entender contextos e correção.
Aprofundamento opcional
- TryHackMe — Web Application PentestingFaça módulos de XSS e client-side attacks.
- PortSwigger — DOM-based vulnerabilitiesAprofundamento para quem terminar cedo.
Prática manual
Audite campos que refletem dados no seu app local: pesquisa, mensagens, nome de arquivo, perfil e parâmetros de URL. Registre contexto e encoding, mesmo quando não houver falha.
Entrega de portfólio
Tabela source → contexto → sink → payload seguro → resultado + relatório de XSS.
Você para de tentar o mesmo `<script>` em todos os lugares e escolhe payload com base no parser e no contexto.
Não usar payloads que enviem cookies ou dados a servidores externos. Uma PoC local visual é suficiente.
S11 CSRF, CORS e confiança no navegadorTestar se o navegador consegue ser induzido a enviar ou expor requisições em nome do usuário. origens ›
Testar se o navegador consegue ser induzido a enviar ou expor requisições em nome do usuário.
Conteúdo que precisa dominar
- CSRF tokens, SameSite e métodos
- CORS preflight, ACAO e credenciais
- Origin e Referer
- Clickjacking
- Mensagens cross-window e postMessage básico
- Diferença entre leitura e envio cross-origin
Laboratórios da semana
- 3 labs de CSRF
- 3 labs de CORS
- 1 lab de clickjacking
- Construir PoC HTML local e explicar pré-condições
Leitura e prática essenciais
- PortSwigger — CSRFLabs essenciais.
- PortSwigger — CORSLabs de origem refletida, null e credenciais.
- WSTG — CSRF and ClickjackingMetodologia de CSRF.
- MDN — CORSBase em português.
Aprofundamento opcional
- TryHackMe — Web Application PentestingUse módulos de CSRF/CORS se precisar de uma introdução mais guiada.
- PortSwigger — ClickjackingFaça 1–2 labs como complemento.
Prática manual
Para três ações sensíveis do seu app, registre método, autenticação, Content-Type, token anti-CSRF, SameSite e validação de Origin/Referer. Teste com PoC local.
Entrega de portfólio
Matriz de proteção cross-origin + duas PoCs seguras e autocontidas.
Você consegue prever quando uma requisição cross-origin será enviada, quando a resposta poderá ser lida e quais controles realmente bloqueiam o ataque.
Não classificar todo CORS permissivo como crítico. Impacto depende de credenciais, dados acessíveis e origem permitida.
S12 Command injection, SSTI e path traversalReconhecer quando entrada do usuário alcança shell, template ou sistema de arquivos. interpretação ›
Reconhecer quando entrada do usuário alcança shell, template ou sistema de arquivos.
Conteúdo que precisa dominar
- OS command injection direto e blind
- Separadores, argumentos e canais laterais
- Server-side template injection
- Path traversal e normalização
- File inclusion como conceito
- Confirmação segura de execução
Laboratórios da semana
- 2–3 labs de command injection
- 2 labs de SSTI
- 2–3 labs de path traversal
- Documentar como cada bypass altera a interpretação
Leitura e prática essenciais
- PortSwigger — OS command injectionLabs diretos e blind.
- PortSwigger — Server-side template injectionComece por identificação e contexto.
- PortSwigger — Path traversalLabs de bypass de filtros.
- WSTG — Input Validation TestingConsulte command injection e file inclusion.
Aprofundamento opcional
- TryHackMe — Web Application PentestingUse os módulos server-side correspondentes.
- PayloadsAllTheThingsUse como referência depois de entender a técnica, não como lista aleatória.
Prática manual
Escolha funcionalidades que lidam com arquivos, conversão, exportação, templates ou comandos em um laboratório. Faça um mapa entrada → componente interpretador → saída observável.
Entrega de portfólio
Mapa de superfícies de interpretação + três mini-relatórios, um por classe.
Você consegue formular uma hipótese sobre o componente interno e escolher testes que confirmem ou refutem essa hipótese.
Não executar comandos destrutivos. Use provas inofensivas, como atraso controlado ou leitura de arquivo de laboratório.
Server-side, arquivos e lógica de negócio
Sair do payload óbvio e aprender a raciocinar sobre integrações, processamento de arquivos, estados, concorrência e regras de negócio.
S13 SSRF e XXETestar integrações que fazem o servidor buscar recursos ou processar XML, incluindo bypasses comuns. server-side ›
Testar integrações que fazem o servidor buscar recursos ou processar XML, incluindo bypasses comuns.
Conteúdo que precisa dominar
- SSRF básico, blind e via redirects
- Allowlist, parsing de URL e DNS
- Metadados cloud como conceito de impacto
- XXE clássico, blind e out-of-band conceitual
- Content-Type e formatos alternativos
- Escopo seguro em chamadas externas
Laboratórios da semana
- 3–4 labs de SSRF
- 2–3 labs de XXE
- Testar redirects e diferentes representações de IP em laboratório
- Diferenciar resposta direta, timing e callback
Leitura e prática essenciais
- PortSwigger — SSRFLabs essenciais e bypass de filtros.
- PortSwigger — XXELabs básicos e blind.
- OWASP SSRF Prevention Cheat SheetLeitura para recomendações.
- WSTG — Input Validation TestingConsulte SSRF e XML injection.
Aprofundamento opcional
- TryHackMe — Web Application PentestingFaça os módulos de SSRF/XXE.
- PortSwigger Collaborator conceptsEntenda OAST; recursos completos podem depender do Burp Pro.
Prática manual
Mapeie funcionalidades de URL: webhook, importação, avatar remoto, PDF, preview, callback e integrações. Para XML, procure upload, SOAP, SVG e conversores.
Entrega de portfólio
Checklist SSRF/XXE aplicado + relatório com cadeia de impacto cuidadosamente limitada.
Você consegue explicar por que bloquear apenas `localhost` ou uma string de IP não resolve SSRF.
Nunca apontar SSRF de alvo real para redes ou serviços que não estejam explicitamente autorizados.
S14 Upload, desserialização e exposição de informaçãoAvaliar processamento de arquivos e objetos sem cair na visão simplista de “extensão permitida”. arquivos e dados ›
Avaliar processamento de arquivos e objetos sem cair na visão simplista de “extensão permitida”.
Conteúdo que precisa dominar
- Validação de nome, tipo, conteúdo e armazenamento
- Execução e acesso público
- Polyglots como conceito
- Desserialização insegura e gadget chains no nível conceitual
- Stack traces, backups e artefatos esquecidos
- Metadados e dados sensíveis em respostas
Laboratórios da semana
- 3 labs de upload
- 2 labs introdutórios de desserialização
- 2 labs de information disclosure
- Testar diferença entre upload, armazenamento, entrega e processamento
Leitura e prática essenciais
- PortSwigger — File upload vulnerabilitiesLabs progressivos.
- PortSwigger — Insecure deserializationFaça os labs iniciais e entenda pré-condições.
- PortSwigger — Information disclosureLabs essenciais.
- WSTG — Configuration and Deployment TestingArquivos, backups e informações expostas.
Aprofundamento opcional
- TryHackMe — Web Application PentestingUse módulos de file upload e deserialization.
- OWASP File Upload Cheat SheetReferência de controles.
Prática manual
Faça inventário de entradas de arquivo em um laboratório: extensão, MIME, magic bytes, nome, caminho, acesso, transformação e remoção. Observe também respostas de erro e arquivos esquecidos.
Entrega de portfólio
Matriz do ciclo de vida do arquivo + relatório de upload ou disclosure.
Você avalia toda a cadeia do arquivo e sabe quando uma desserialização é apenas possível ou realmente explorável.
Não enviar malware real. Use arquivos de prova inofensivos e somente em ambiente autorizado.
S15 Falhas de lógica, race conditions e WebSocketsEncontrar vulnerabilidades que scanners dificilmente identificam porque dependem de estado, concorrência e regras de negócio. manual ›
Encontrar vulnerabilidades que scanners dificilmente identificam porque dependem de estado, concorrência e regras de negócio.
Conteúdo que precisa dominar
- Invariantes e abuse cases
- Preço, quantidade, limites e cupons
- Estados fora de ordem
- Race conditions e ações simultâneas
- WebSockets, mensagens e autorização
- Impacto financeiro e operacional
Laboratórios da semana
- 3–4 labs de lógica
- 2 labs de race condition
- 1–2 labs de WebSockets
- Para cada falha, escrever a invariante que deveria permanecer verdadeira
Leitura e prática essenciais
- PortSwigger — Business logic vulnerabilitiesFaça labs variados e registre o raciocínio.
- PortSwigger — Race conditionsConceitos e labs iniciais.
- PortSwigger — WebSocketsInterceptação e manipulação.
- WSTG — Business Logic TestingTransforme itens em perguntas para o sistema.
Aprofundamento opcional
- TryHackMe — Web Application PentestingPriorize módulos de logic flaws e race conditions.
- PortSwigger — Mystery lab challengeEscolha um lab sem olhar o tópico para testar metodologia.
Prática manual
Escolha um processo com valor de negócio: compra, convite, limite, aprovação, saldo ou permissão. Liste pré-condições, invariantes, estados e operações concorrentes; teste no laboratório.
Entrega de portfólio
Documento de abuse cases + relatório com impacto de negócio, não apenas impacto técnico.
Você consegue explicar a regra quebrada em uma frase e demonstrar um caminho reproduzível para quebrá-la.
Não reduzir pentest a payloads. Nesta semana, perguntas sobre o negócio valem mais que listas de strings.
S16 Avaliação integrada do OWASP Juice ShopExecutar uma avaliação web curta sem saber previamente qual vulnerabilidade procurar. sem roteiro ›
Executar uma avaliação web curta sem saber previamente qual vulnerabilidade procurar.
Conteúdo que precisa dominar
- Mapeamento de superfície
- Priorização de funcionalidades
- Teste por hipótese
- Controle de tempo e cobertura
- Encadeamento responsável
- Organização de evidências
Laboratórios da semana
- Definir escopo e tempo antes de iniciar
- Mapear aplicação por 90 minutos sem explorar
- Executar testes por 5 horas
- Reservar 2 horas para relatório e 1 hora para retrospectiva
Leitura e prática essenciais
- OWASP Juice ShopUse instalação local; não abra o guia de soluções no início.
- WSTG — StableUse como checklist de cobertura, não como walkthrough.
- PortSwigger — All topicsConsulte somente para revisar técnicas já estudadas.
Aprofundamento opcional
- Hacker101 CTFUse como alvo alternativo se já conhece o Juice Shop.
- TryHackMe — Web Application PentestingEscolha um laboratório integrado, sem repetir passo a passo.
Prática manual
Faça uma avaliação de 8 horas distribuídas na semana. Só consulte dicas depois de registrar hipótese, tentativa, resultado e motivo do bloqueio.
Entrega de portfólio
Relatório de pentest do Juice Shop com resumo executivo, metodologia, cobertura, achados, evidências e limitações.
Você consegue manter organização quando ninguém informa qual falha existe e termina com um relatório utilizável.
Não medir sucesso apenas pelo número de desafios resolvidos. Cobertura, raciocínio e comunicação também contam.
Pentest de APIs
Transformar sua experiência de fullstack em vantagem ofensiva. Mapear contratos, objetos, propriedades, funções e fluxos de negócio em REST e GraphQL.
S17 Mapeamento de APIs REST e contratos OpenAPIDescobrir e organizar endpoints, versões, objetos, propriedades e fluxos sem depender da interface web. API recon ›
Descobrir e organizar endpoints, versões, objetos, propriedades e fluxos sem depender da interface web.
Conteúdo que precisa dominar
- REST, recursos e métodos
- JSON e Content-Type
- OpenAPI/Swagger e documentação exposta
- Versionamento e endpoints antigos
- Parâmetros em path, query, header e body
- Inventário de objetos e identificadores
Laboratórios da semana
- Mapear API pelo histórico do Burp
- Procurar especificações OpenAPI e endpoints não usados pela UI
- Testar métodos alternativos e versões
- Criar inventário endpoint × método × auth × objeto
Leitura e prática essenciais
- PortSwigger — API testingComece por API recon e documentação.
- OWASP API Security Top 10:2023Leia as dez categorias e exemplos.
- OWASP WSTG — API TestingUse quando disponível na versão stable/latest; complemente com o projeto API Security.
- OWASP crAPIPrepare o laboratório para as próximas semanas.
Aprofundamento opcional
- TryHackMe — Web Application PentestingFaça a seção de API security e API recon.
- OpenAPI SpecificationConsulte estrutura de paths, parameters e schemas.
Prática manual
Escolha uma API de laboratório e reconstrua uma documentação mínima apenas observando tráfego e respostas. Depois compare com Swagger/OpenAPI, se existir.
Entrega de portfólio
Inventário de API em CSV/Markdown + mapa de objetos e identificadores.
Você consegue navegar e testar a API sem depender do frontend e identifica lacunas entre documentação e implementação.
Não usar fuzzing massivo antes de entender o contrato e os limites do laboratório.
S18 Autenticação de API, BOLA e BFLATestar identidade, objetos e funções em APIs usando múltiplos usuários e perfis. API access ›
Testar identidade, objetos e funções em APIs usando múltiplos usuários e perfis.
Conteúdo que precisa dominar
- API2 Broken Authentication
- API1 BOLA
- API5 Broken Function Level Authorization
- Tokens em headers e cookies
- Escopos e claims
- Multi-tenant e contexto de organização
Laboratórios da semana
- Criar pelo menos dois usuários e dois papéis no crAPI/lab
- Trocar objetos em todos os métodos
- Testar funções administrativas por rota e método
- Modificar claims apenas para verificar se o servidor confia neles
Leitura e prática essenciais
- OWASP API1:2023 BOLARisco e cenários.
- OWASP API2:2023 Broken AuthenticationFluxos de autenticação de API.
- OWASP API5:2023 BFLAFunções administrativas e métodos.
- PortSwigger — API testingLabs de autorização e mass assignment relacionados.
Aprofundamento opcional
- TryHackMe — Web Application PentestingUse módulos de API authentication e authorization.
- OWASP REST Security Cheat SheetReferência para recomendações.
Prática manual
Monte uma matriz API: token/usuário × endpoint × método × objeto × resultado esperado. Execute testes positivos e negativos.
Entrega de portfólio
Matriz de autorização de API + dois relatórios: objeto e função.
Você diferencia BOLA de BFLA e demonstra a decisão de autorização ausente no ponto correto.
Não presumir que endpoint não listado no frontend está fora de uso ou protegido.
S19 Propriedades, mass assignment, recursos e fluxos sensíveisTestar riscos específicos de API além de IDs e login. API business ›
Testar riscos específicos de API além de IDs e login.
Conteúdo que precisa dominar
- API3 Broken Object Property Level Authorization
- Leitura excessiva e alteração de propriedades
- Mass assignment
- API4 Unrestricted Resource Consumption
- API6 Sensitive Business Flows
- API7 SSRF e API10 Unsafe Consumption
- Paginação, filtros, batch e exportação
Laboratórios da semana
- Adicionar propriedades não presentes na UI
- Remover campos e observar defaults
- Alterar paginação, tamanho, filtros e batch
- Testar repetição segura de fluxo sensível em laboratório
- Investigar chamadas a APIs de terceiros
Leitura e prática essenciais
- OWASP API3:2023 BOPLAExposição e alteração de propriedades.
- OWASP API4:2023 Resource ConsumptionCustos, limites e disponibilidade.
- OWASP API6:2023 Sensitive Business FlowsAutomação de fluxos de valor.
- OWASP API Security Top 10:2023Revise API7–API10.
Aprofundamento opcional
- TryHackMe — Web Application PentestingUse módulos avançados de API.
- PortSwigger — API testingLabs de mass assignment e server-side parameter pollution.
Prática manual
Pegue três objetos da API e registre propriedades de leitura, criação e atualização por perfil. Depois teste limites de volume e automação com valores pequenos e controlados.
Entrega de portfólio
Matriz de propriedades + relatório de mass assignment/BOPLA + nota de risco de consumo/automação.
Você testa o schema e o comportamento do objeto, não apenas a URL do endpoint.
Não causar negação de serviço. Teste limites com carga mínima e somente quando o ambiente autorizar.
S20 GraphQL e avaliação integrada do crAPITestar GraphQL e consolidar uma avaliação completa de API REST. API capstone ›
Testar GraphQL e consolidar uma avaliação completa de API REST.
Conteúdo que precisa dominar
- Schema, queries, mutations e resolvers
- Introspection e sugestões de campo
- Aliases, batching e profundidade
- Autorização por resolver e objeto
- Erros e exposição de schema
- Metodologia completa de API
Laboratórios da semana
- 3 labs de GraphQL
- Mapear crAPI sem guia de soluções
- Executar testes por categoria do API Top 10
- Produzir relatório integrado de API
Leitura e prática essenciais
- PortSwigger — GraphQL API vulnerabilitiesLabs essenciais.
- OWASP GraphQL Cheat SheetControles e perguntas de teste.
- OWASP crAPIAlvo principal da avaliação.
- OWASP API Security Top 10:2023Use como matriz final de cobertura.
Aprofundamento opcional
- TryHackMe — Web Application PentestingUse módulos de GraphQL/API avançada.
- PortSwigger — WebSocketsÚtil quando GraphQL usa subscriptions.
Prática manual
Reserve seis horas para o crAPI: uma para mapeamento, quatro para testes e uma para organizar evidências. Use uma conta por perfil quando possível.
Entrega de portfólio
Relatório de pentest de API do crAPI + inventário de endpoints + matriz OWASP API Top 10.
Você executa um teste de API com método próprio e consegue defender a cobertura e as limitações do trabalho.
Não abrir walkthrough antes de terminar sua primeira rodada e registrar os pontos cegos.
Trabalho profissional e portfólio
Executar um teste com começo, meio e fim: escopo, plano, evidências, severidade, relatório, reteste e comunicação. Bug bounty entra como treino autorizado, não como renda principal.
S21 Recon, escopo e plano de teste profissionalPlanejar uma avaliação com limites claros, cobertura justificável e uso responsável de automação. engagement ›
Planejar uma avaliação com limites claros, cobertura justificável e uso responsável de automação.
Conteúdo que precisa dominar
- Regras de engajamento
- Ativos, ambientes e contas
- Testes permitidos e proibidos
- Recon passivo e ativo no escopo
- Checklist baseado em risco
- Estimativa, timeboxing e registro de cobertura
Laboratórios da semana
- Escrever regras de engajamento para um laboratório
- Selecionar casos WSTG por arquitetura e risco
- Criar planilha de cobertura e evidências
- Realizar recon limitado e justificar cada ferramenta
Leitura e prática essenciais
- OWASP WSTG — StableUse IDs WSTG para organizar casos de teste.
- OWASP Testing Guide — Penetration Testing MethodologiesCompare abordagens.
- PortSwigger — Web Security Academy topicsTransforme tópicos relevantes em plano, não em lista infinita.
- HackerOne — Code of ConductReferência de comportamento responsável em plataforma.
Aprofundamento opcional
- TryHackMe — Guided Pentest/Web App PentestingUse um módulo integrado para observar as etapas do engagement.
- OWASP ASVSConsulte requisitos para ampliar casos de teste, sem transformar o trabalho em auditoria completa.
Prática manual
Escolha Juice Shop, crAPI ou outro laboratório e produza um plano de teste de duas páginas antes de abrir o Burp.
Entrega de portfólio
Documento de escopo + plano de teste + matriz de cobertura e limitações.
Outra pessoa entende exatamente o que será testado, o que não será, como evidências serão registradas e quando parar.
Não confundir quantidade de ferramentas com cobertura. Cada ação precisa responder a uma hipótese ou caso de teste.
S22 Relatórios, CVSS v4.0 e retesteEntregar resultados tecnicamente corretos, priorizáveis e verificáveis. comunicação ›
Entregar resultados tecnicamente corretos, priorizáveis e verificáveis.
Conteúdo que precisa dominar
- Título e resumo orientados ao risco
- Pré-condições e passos mínimos
- Evidências antes/depois
- CWE e CVSS v4.0
- Severidade versus risco de negócio
- Recomendação sem escrever a correção
- Reteste, residual risk e fechamento
Laboratórios da semana
- Reescrever três achados antigos
- Pontuar os mesmos achados com CVSS v4.0
- Criar evidência de reteste corrigido e não corrigido
- Produzir resumo executivo de uma página
Leitura e prática essenciais
- FIRST CVSS v4.0Leia a visão geral e o User Guide.
- CVSS v4.0 CalculatorRegistre vetor e justificativa.
- CVSS v4.0 ExamplesCompare decisões de pontuação.
- MITRE CWEUse a fraqueza raiz, não apenas um termo genérico.
Aprofundamento opcional
- HackerOne HacktivityCompare seus achados com relatórios divulgados.
- Hacker101Revise materiais sobre reporting e impacto.
Prática manual
Pegue o relatório da semana 16 ou 20 e transforme-o em um pacote profissional: relatório executivo, relatório técnico e planilha de achados.
Entrega de portfólio
Relatório final revisado + planilha de achados + modelo de reteste.
Cada severidade possui vetor e justificativa; cada achado possui impacto, reprodução, recomendação e condição objetiva de reteste.
Não usar CVSS como sinônimo automático de prioridade. Contexto do ativo e do negócio também precisa ser comunicado.
S23 Primeiro teste externo autorizado e bug bounty como treinoAplicar metodologia em um alvo com regras reais sem transformar recompensa em objetivo principal. escopo real ›
Aplicar metodologia em um alvo com regras reais sem transformar recompensa em objetivo principal.
Conteúdo que precisa dominar
- VDP versus bug bounty
- Leitura de escopo e safe harbor
- Duplicado, informativo e N/A
- Teste proporcional e minimização de impacto
- Comunicação com o programa
- Diário de hipóteses e pontos cegos
Laboratórios da semana
- Escolher um VDP/programa público com regras claras ou permanecer em CTF
- Ler escopo três vezes e registrar proibições
- Focar em uma única funcionalidade e uma classe de falha
- Produzir submissão somente com evidência suficiente
Leitura e prática essenciais
- HackerOne HacktivityLeia relatórios do tipo de alvo escolhido.
- Hacker101 CTFAlternativa segura se ainda não se sentir pronto para um programa.
- TryHackMe — Web Application PentestingUse um guided pentest ou finalize módulos pendentes antes do alvo externo.
- TryHackMe — praticar web pentest com segurançaReforce limites e prática autorizada.
Aprofundamento opcional
- Bugcrowd UniversityMateriais de metodologia e reporting.
- PortSwigger ResearchLeia um artigo e identifique quais pré-requisitos ainda faltam.
Prática manual
Realize seis horas de teste autorizado. Mantenha diário com hipótese, ação, resultado e próxima decisão. Pare imediatamente ao encontrar limite de escopo ou risco de impacto.
Entrega de portfólio
Um report submetido ou um relatório privado equivalente de CTF/laboratório + retrospectiva sobre duplicados, lacunas e eficiência.
Você segue escopo mesmo quando uma pista interessante leva para fora dele e consegue produzir um relatório responsável.
Não testar sistema do empregador, clientes, vizinhos ou qualquer terceiro sem autorização explícita e documentada.
S24 Capstone, portfólio e preparação para vagasConsolidar evidências de competência para Web/API Pentest e definir os próximos seis meses. carreira ›
Consolidar evidências de competência para Web/API Pentest e definir os próximos seis meses.
Conteúdo que precisa dominar
- Portfólio sem dados sensíveis
- Apresentação de metodologia
- Entrevista técnica e demonstração no Burp
- Histórias de investigação e comunicação
- Lacunas técnicas e plano de continuidade
- Certificações como opção, não atalho
Laboratórios da semana
- Escolher alvo de laboratório novo
- Planejar e executar avaliação de 6 horas
- Produzir relatório em 2 horas
- Apresentar um achado em 10 minutos como entrevista
Leitura e prática essenciais
- Seus relatórios e matrizesSelecione e higienize artefatos produzidos nas 23 semanas.
- PortSwigger Web Security AcademyRevise progresso e tópicos não concluídos.
- Hacker101Use CTF e materiais como continuidade gratuita.
- TryHackMe — Web Application PentestingRevise módulos úteis e ignore os que não atendem seu foco.
Aprofundamento opcional
- Burp Suite Certified PractitionerMeta futura depois de dominar labs Practitioner; não é obrigatória para buscar vaga.
- OWASP ChaptersParticipe de encontros e apresente uma experiência de laboratório.
Prática manual
Monte um repositório público higienizado com metodologia, dois relatórios de laboratório, uma matriz de autorização, um mapa de API, um template de achado e uma retrospectiva. Não publique payloads contra alvos reais nem dados de terceiros.
Entrega de portfólio
Capstone Web/API Pentest + portfólio público + currículo/LinkedIn ajustados para Application Security Testing ou Web/API Pentest.
Você consegue demonstrar ao vivo como mapeia, testa, valida, classifica e comunica uma falha, sem depender de dizer apenas quais cursos concluiu.
Não esperar “sentir-se pronto”. Após o capstone, comece a se candidatar e use entrevistas para calibrar lacunas.