Bug Bounty: Guia Completo para Iniciantes (2026)

O que é bug bounty?

O que é bug bounty? Bug bounty é a prática de encontrar vulnerabilidades de segurança nos sistemas de uma empresa e relatá-las por meio de um programa de recompensa oficial, em troca de pagamento ou reconhecimento. A empresa publica um escopo do que você está autorizado a testar e paga conforme a gravidade de cada bug confirmado.

Pense nisso como teste de intrusão legal e pago por resultado. Um pentester tradicional é contratado por um valor fixo para testar um conjunto de alvos acordado ao longo de uma ou duas semanas. Um caçador de bugs testa os mesmos tipos de alvo, mas só é pago pelo que encontra, e pode caçar quando quiser. A troca é estabilidade por liberdade: sem renda garantida, sem horário fixo e sem teto para quanto uma única grande descoberta pode pagar.

As empresas mantêm esses programas porque sai mais barato que a alternativa. Pagar alguns milhares de dólares a um hacker por uma falha custa muito menos que um vazamento, e coloca centenas de testadores no alvo em vez de um só consultor. Os programas são coordenados pelo modelo de divulgação responsável, no qual os pesquisadores relatam em privado e a empresa corrige o problema antes de qualquer detalhe público sair.

Bug bounty é uma das formas mais comuns de sair do aprendizado de segurança para ser pago por ele, ao lado da carreira de teste de intrusão. Muitos caçadores fazem os dois, usando as recompensas para manter as habilidades afiadas entre projetos.

Como funcionam os programas de bug bounty

Todo programa funciona com as mesmas poucas engrenagens. Entenda estes cinco elementos e você conseguirá ler qualquer página de programa sabendo exatamente o que pode fazer e quanto isso paga.

Escopo

O escopo é a lista de ativos que você tem permissão para testar, geralmente domínios específicos, aplicativos móveis ou endpoints de API. Qualquer coisa fora da lista está fora de escopo, e testá-la é acesso não autorizado, ponto final. O escopo também especifica técnicas proibidas, mais comumente varredura automatizada que martela o alvo, engenharia social de funcionários e testes de negação de serviço. Leia esta seção duas vezes antes de tocar em qualquer coisa.

Gravidade e tabelas de recompensa

A maioria dos programas classifica as descobertas usando o Common Vulnerability Scoring System (CVSS), agrupando-as em baixo, médio, alto ou crítico. Cada nível corresponde a uma faixa de pagamento publicada na página do programa. Um bug crítico de execução remota de código em um banco pode pagar 20.000 dólares, enquanto um problema de baixa gravidade em um subdomínio de marketing paga 50.

Triagem

Quando você envia, um analista de triagem (muitas vezes equipe da plataforma, não da empresa) reproduz seu relatório e decide se ele é válido, duplicado ou fora de escopo. Este é o portão pelo qual todo relatório passa, e um relato claro e reproduzível é o que faz você passar rapidamente.

Duplicados

Se alguém relatou o mesmo bug antes de você, o seu é marcado como duplicado e não paga nada. Esta é a parte mais frustrante da caça e o motivo pelo qual velocidade e originalidade importam. Programas populares recebem os bugs óbvios nas primeiras horas após o lançamento.

Divulgação

Depois que uma correção é lançada, alguns programas permitem publicar o relatório, o que constrói sua reputação. Outros mantêm tudo em sigilo. De qualquer forma, divulgar detalhes antes de a empresa autorizar quebra as regras e pode fazer você ser banido.

Quanto os caçadores de bugs realmente ganham?

Quanto ganham os caçadores de bugs? Os ganhos vão de nada a seis dígitos por ano, e a maioria dos caçadores fica perto da base dessa faixa. Os pagamentos dependem inteiramente da gravidade do que você encontra e de quanta concorrência você supera até o relatório, então a renda é real, mas muito irregular.

Os números no nível das plataformas são genuinamente grandes. A HackerOne informou que seus programas pagaram cerca de 81 milhões de dólares em recompensas nos doze meses até meados de 2025, alta de cerca de 13 por cento no ano, segundo seu balanço anual do programa. O programa de recompensa por vulnerabilidades do Google pagou perto de 12 milhões de dólares a pesquisadores só em 2024. O dinheiro no sistema não é mito.

O detalhe é a distribuição. Esse bolo é dividido de forma muito desigual, com um pequeno grupo de caçadores de elite em tempo integral levando uma grande fatia, enquanto a longa cauda de amadores de meio período ganha valores modestos ou nada em um dado mês. Um primeiro ano realista para um iniciante dedicado se parece com um punhado de descobertas de baixa a média gravidade, não com um salário de tempo integral.

Aqui está o enquadramento honesto que dou a quem está começando: trate seu primeiro ano como educação remunerada. Você está sendo recompensado, às vezes, pela mesma prática que te torna empregável em segurança, independentemente de as recompensas se tornarem ou não um dia sua renda principal. Mantenha um emprego ou os estudos rodando por baixo. Os caçadores que se esgotam são os que apostam o dinheiro do aluguel no surgimento de críticos sem duplicados em data marcada. Isso não acontece.

Como começar em bug bounty: um roteiro em 6 passos

O caminho do zero até um relatório válido não é complicado, mas é fácil pular etapas e perder meses. Siga esta ordem.

1. Aprenda como a web funciona. Requisições e respostas HTTP, cookies, cabeçalhos, códigos de status e como um navegador conversa com um servidor. Não dá para achar uma falha em um sistema que você não entende. Se termos como GET, POST e redirecionamento 302 são vagos, comece por aí.
2. Escolha uma classe de vulnerabilidade e aprenda-a a fundo. Não tente aprender todos os tipos de bug de uma vez. Escolha um que pague bem e seja amigável a iniciantes, como controle de acesso ou IDOR, e entenda-o de ponta a ponta antes de adicionar um segundo.
3. Pratique em alvos seguros e propositalmente vulneráveis. Treine essa classe de bug em ambientes de lab feitos para serem quebrados, onde não há risco legal nem duplicado para roubar sua descoberta. É aqui que o aprendizado de verdade acontece.
4. Monte suas ferramentas. Um proxy de interceptação é indispensável. Aprenda o Burp Suite bem o suficiente para interceptar, modificar e repetir requisições, porque quase toda a caça web passa por ele.
5. Escolha um programa amigável a iniciantes com escopo amplo. Escopos maiores significam mais superfície de ataque e mais bugs que a multidão ainda não limpou. Leia toda a página do programa, anote o que é proibido e foque em um ativo em vez de varrer tudo.
6. Cace estreito, relate limpo. Teste sua única classe de bug de forma sistemática nesse único ativo. Quando encontrar algo, reproduza duas vezes e então documente com clareza. Um bug válido bem documentado vale mais que cinquenta envios pela metade que acabam todos fechados.

Na prática, a maioria dos iniciantes bem-sucedidos passa muito mais tempo nos passos dois e três do que espera. As pessoas que relatam um bug válido no primeiro mês quase sempre chegam já fluentes em uma vulnerabilidade, depois de meses de prática em lab. Não há atalho para as repetições.

As vulnerabilidades que realmente pagam

Nem todos os bugs são iguais, e iniciantes perdem tempo perseguindo classes raras e difíceis de explorar quando os geradores confiáveis de renda são mais acessíveis. Estes são os tipos de vulnerabilidade que mais aparecem nas recompensas de iniciantes, todos mapeados no OWASP Top 10.

Controle de acesso quebrado e IDOR

O controle de acesso é a categoria número um do OWASP Top 10 por um motivo: está em toda parte e muitas vezes é trivial de testar. Uma Referência Direta Insegura a Objeto (IDOR) ocorre quando você muda um ID em uma requisição, digamos de /account/1023 para /account/1024, e o servidor te entrega os dados de outra pessoa sem verificar se você deveria vê-los. Sem código de exploração, apenas um valor que você edita. Nosso guia sobre controle de acesso quebrado cobre a abordagem completa de teste.

Cross-Site Scripting (XSS)

O XSS permite injetar JavaScript que roda no navegador de outro usuário, o que pode roubar sessões ou executar ações em seu nome. É um dos bugs web mais relatados porque uma entrada refletida de volta em uma página sem codificação adequada é extremamente comum. Veja nosso tutorial de cross-site scripting para saber como encontrá-lo e confirmá-lo.

Server-Side Request Forgery (SSRF)

O SSRF engana um servidor para que ele faça requisições em seu nome, muitas vezes alcançando sistemas internos que um usuário normal jamais poderia tocar. Em infraestrutura de nuvem, pode expor endpoints de metadados com credenciais, e é por isso que costuma pagar como alto ou crítico. O guia de SSRF detalha os alvos internos que valem a pena alcançar.

Injeção de SQL

A injeção de SQL é mais antiga e mais bem defendida do que costumava ser, mas ainda surge em endpoints legados e paga bem quando surge, porque frequentemente significa acesso direto ao banco de dados. Aprenda os padrões em nosso material de injeção de SQL e pratique-os antes de caçar ao vivo.

Falhas de lógica de negócio

Esses são os bugs que os scanners nunca encontram: comprar um item por preço negativo, pular uma etapa de pagamento ou aplicar um cupom mil vezes. Eles exigem entender o que a aplicação deveria fazer e então quebrar essa intenção. São mais difíceis de notar, mas raramente duplicados, o que os torna algumas das descobertas mais rentáveis para um caçador paciente.

Metodologia de bug bounty: do reconhecimento ao relatório

Uma metodologia é só um processo repetível para você não cutucar alvos ao acaso. A maioria dos caçadores segue uma versão deste ciclo.

Reconhecimento

Reconhecimento é mapear a superfície de ataque do alvo antes de testar qualquer coisa. Para um programa de escopo amplo, isso significa enumerar subdomínios, descobrir endpoints e catalogar cada entrada que a aplicação aceita. Quanto mais superfície você mapeia, mais lugares um bug tem para se esconder. Ferramentas de descoberta de diretórios e conteúdo ajudam a revelar páginas que o site nunca vincula.

Análise de vulnerabilidade

Com o mapa em mãos, você procura a classe de bug específica na qual treinou. É aqui que você envia requisições forjadas pelo seu proxy, observa como a aplicação responde e nota os pequenos desvios que denunciam uma falha. Disciplina aqui significa testar uma hipótese de cada vez em vez de disparar payloads às cegas.

Exploração e impacto

Encontrar um comportamento estranho não basta. Você precisa provar impacto real. Um valor refletido é interessante; um payload funcional que rouba um cookie de sessão é um relatório pago. As equipes de triagem recompensam o impacto demonstrado, então construa a prova de conceito mais limpa possível que mostre o que um atacante poderia de fato fazer.

Ao testar programas reais, resista à vontade de escalar além do que prova o ponto. Ler o registro de um único outro usuário prova um IDOR. Despejar dez mil registros para parecer assustador é a forma de ser removido de um programa e, dependendo dos dados, cruzar uma linha legal. Prove o impacto e então pare.

Melhores plataformas de bug bounty em 2026

Quase todos os programas são hospedados em um punhado de plataformas que cuidam do escopo, dos envios, da triagem e do pagamento. Aqui está por onde os iniciantes realmente começam, com uma nota honesta sobre cada uma.

Meu conselho direto: comece na HackerOne ou na Bugcrowd. Elas têm mais programas, a integração mais clara e o maior conjunto de alvos de escopo amplo onde um iniciante ainda pode achar algo que a multidão deixou passar. Mirar um crítico no VRP do Google como seu primeiro alvo é o caminho mais rápido para o desânimo. Construa vitórias em programas acessíveis primeiro.

Como escrever um relatório de bug bounty que paga

Como escrever um bom relatório de bug bounty? Um bom relatório permite que um analista de triagem reproduza seu bug em menos de cinco minutos sem te fazer uma única pergunta. Ele declara a vulnerabilidade, seu impacto e os passos exatos de reprodução em linguagem clara, apoiado por evidências. É a clareza, não o tamanho, que faz você ser pago.

Relatórios fracos são o motivo mais comum de bugs válidos pagarem menos do que deveriam, ou serem fechados de vez. Um bom relatório tem um formato previsível:

• Título. Uma linha nomeando o bug e onde ele está, como "IDOR no endpoint de fatura expõe dados de cobrança de outros usuários".
• Resumo. Duas ou três frases sobre o que é a falha e por que ela importa.
• Passos para reproduzir. Uma lista numerada que um estranho consegue seguir exatamente, incluindo a requisição, o parâmetro que você alterou e o resultado esperado versus o obtido.
• Impacto. O que um atacante ganha em termos concretos, ligado a dados ou ações reais, não uma vaga linguagem de "isso é perigoso".
• Evidência. Capturas de tela, a requisição e a resposta brutas, ou um vídeo curto. Mostre o bug, não apenas o descreva.

Escreva a seção de impacto para um não-hacker. A pessoa que decide seu pagamento pode ser um gerente de produto que precisa entender o risco de negócio em uma leitura. "Um atacante pode ver e alterar o cartão de pagamento salvo de qualquer cliente" impacta mais que um muro de jargão técnico. Nosso curso Bug Bounty Fundamentals inclui um capítulo inteiro sobre relatórios, com exemplos reais de relatórios que passaram pela triagem sem problemas.

Erros comuns de iniciantes

A maioria das pessoas que abandona a caça de bugs cedo comete os mesmos erros evitáveis. Evite-os e você já estará à frente da maior parte do campo.

• Testar fora do escopo. A forma mais rápida de ser banido e, na pior das hipóteses, denunciado às autoridades. Leia o escopo, respeite-o exatamente.
• Aprender tudo, dominar nada. Pular entre dez tipos de bug significa que você é fraco em todos. Profundidade em uma classe vale mais que familiaridade superficial com todas.
• Depender de scanners automatizados. Todo mundo usa as mesmas ferramentas, então os bugs que elas acham já estão relatados. Sua vantagem é o teste manual e o entendimento, não um scanner que todos os outros também têm.
• Pular os labs de treino. Caçar ao vivo antes de conseguir achar um bug de forma confiável em um lab desperdiça meses em programas onde você não reconheceria uma falha na sua frente.
• Desistir depois de duplicados. Suas primeiras descobertas válidas serem duplicados é normal, não um sinal de que você é ruim. Significa que você está procurando nos lugares certos, só que ainda não rápido o bastante. Continue.

Considerações legais e éticas

Todo o modelo depende de permanecer dentro do escopo autorizado e seguir a divulgação responsável. Relate em privado, nunca extraia mais dados do que o necessário para provar o impacto, e nunca divulgue detalhes publicamente até o programa permitir. Cruze qualquer uma dessas linhas e um programa de recompensa legal vira um crime informático.

Existem exatamente três lugares para praticar essas técnicas de forma legal: programas de bug bounty dentro do escopo publicado, projetos remunerados sob contrato assinado e plataformas de lab isoladas feitas para serem atacadas. Os labs de desafios da HackerDNA se enquadram na terceira categoria, oferecendo alvos vulneráveis reais sem risco legal enquanto você desenvolve as habilidades para as duas primeiras.