Pentest de aplicações: o guia completo para lançar com segurança

O que é pentest

Pentest (teste de invasão) é uma avaliação de segurança ofensiva em que um especialista, com autorização formal, tenta explorar o seu sistema da mesma forma que um atacante faria. O objetivo não é apenas listar alertas, mas provar quais falhas são realmente exploráveis e qual o impacto delas para o negócio.

Diferente de uma auditoria de conformidade, o pentest é prático: ele reproduz ataques reais contra a aplicação, as APIs e, quando faz parte do escopo, a infraestrutura e os processos que a cercam. O resultado é um retrato do risco que existe hoje, com evidências que o seu time consegue usar para corrigir.

Na prática, um pentest responde a três perguntas: o que pode dar errado, quão grave é e como corrigir. É esse encadeamento — risco, evidência e correção — que transforma o teste em decisão de engenharia, e não em uma lista interminável de checks.

Pentest não é a mesma coisa que scanner automático

Ferramentas automatizadas são úteis e fazem parte do trabalho, mas sozinhas elas encontram sobretudo problemas conhecidos e superficiais. Um scanner não entende regra de negócio, não encadeia falhas e não percebe quando um dado sensível está exposto por uma decisão de produto.

O pentest combina ferramentas com análise manual e raciocínio sobre o fluxo da aplicação. É aí que aparecem as falhas mais graves: uma checagem de autorização ausente, uma mudança de IDOR, um fluxo de recuperação de senha quebrado ou uma integração que confia demais em outra.

• ✓ O scanner encontra assinaturas conhecidas; o pentest encontra falhas de lógica e de autorização.
• ✓ O scanner gera muitos alertas; o pentest prioriza o que é explorável.
• ✓ O scanner não encadeia falhas; o pentest mostra o caminho real do atacante.

O que um pentest costuma avaliar

A profundidade depende do escopo, mas as frentes abaixo cobrem a maior parte dos riscos explorados em aplicações modernas. Elas seguem, como referência, o OWASP Top 10 e o OWASP API Top 10.

Avaliamos desde as falhas clássicas de injeção até as que mais causam prejuízo hoje: ausência de controle de acesso, exposição de dados e problemas em autenticação e sessão.

• ✓ Controle de acesso (incluindo IDOR, BOLA e BFLA).
• ✓ Autenticação, sessão e gestão de tokens.
• ✓ Injeções (SQL, comandos, templates) e validação de entrada.
• ✓ Exposição de dados sensíveis e má configuração.
• ✓ Lógica de negócio e regras do produto.
• ✓ Dependências, componentes desatualizados e segredos expostos.

Caixa-preta, caixa-cinza e caixa-branca

No pentest de caixa-preta, o avaliador não recebe informações privilegiadas e simula um atacante externo. Esse formato testa o que é alcançável sem conhecimento prévio e costuma ser mais lento e menos profundo em falhas internas.

No caixa-cinza, há alguma informação — credenciais de teste, documentação parcial ou acesso a um ambiente de homologação. É o formato mais eficiente para cobrir um sistema real em tempo hábil, pois concentra esforço onde há mais risco.

No caixa-branca, o avaliador tem acesso ao código-fonte e ao desenho da aplicação. Isso permite encontrar falhas de forma mais completa e explicar a causa raiz, o que ajuda o time a corrigir de vez, e não só no ponto onde a falha apareceu.

Como funciona o processo

Um pentest bem executado tem começo, meio e fim claros. Antes de qualquer teste, definimos por escrito o que será avaliado, o que está fora do escopo e quais técnicas são permitidas. Isso protege os dois lados e evita surpresas.

Só então vem a execução, seguida da entrega dos achados e, conforme o escopo, do reteste das correções. Cada etapa existe para que o resultado seja confiável e acionável.

• ✓ Planejamento e escopo autorizado por escrito.
• ✓ Reconhecimento e mapeamento da superfície.
• ✓ Testes manuais e com ferramentas, guiados pelo OWASP.
• ✓ Exploração controlada, com prova de conceito.
• ✓ Relatório com evidências e severidade.
• ✓ Reteste das correções (conforme o escopo).

O que você recebe

O entregável é um relatório que serve a duas audiências: a técnica, que precisa reproduzir e corrigir; e a de negócio, que precisa entender o risco e priorizar investimento.

Cada achado tem descrição, evidência reproduzível, severidade e recomendação. É o que permite ao seu time agir sem depender do fornecedor para cada passo.

• ✓ Relatório técnico e executivo.
• ✓ Evidências reproduzíveis (passos e resultado).
• ✓ Severidade (CVSS quando aplicável) e impacto de negócio.
• ✓ Recomendações priorizadas por risco.
• ✓ Sessão de apresentação dos achados.

Como priorizar: severidade técnica e risco de negócio

Nem toda vulnerabilidade merece a mesma urgência. A severidade técnica mede o quão explorável e impactante é a falha; o risco de negócio soma o contexto: quais dados estão em jogo, quem alcança o sistema e qual o custo de uma indisponibilidade.

Uma falha tecnicamente média pode ser crítica se expõe dados de milhares de clientes. Por isso priorizamos pelo risco real, e não pela contagem de achados. O objetivo é que a primeira correção seja a que mais reduz risco.

Quando contratar um pentest

O melhor momento é antes de expor algo novo a usuários reais, quando corrigir ainda é barato. Também vale quando o produto muda de forma relevante, quando há exigência de clientes ou de compliance e depois de um incidente.

Fazer pentest de forma recorrente é mais eficaz do que uma avaliação isolada, porque o produto continua mudando. Reavaliar as áreas críticas a cada ciclo mantém o risco sob controle.

• ✓ Antes de lançamentos e grandes mudanças.
• ✓ Ao lidar com dados sensíveis ou pagamentos.
• ✓ Para atender exigências de clientes e de compliance.
• ✓ Após um incidente ou suspeita de comprometimento.
• ✓ Como rotina de segurança contínua.

Web, mobile e APIs: o que muda

Aplicações web concentram riscos de sessão, controle de acesso e entrada de dados. Aplicações mobile acrescentam o armazenamento local, a comunicação com o backend e a proteção do binário. APIs expõem diretamente a lógica e os dados, e costumam sofrer com falhas de autorização por objeto e por função.

Por isso o escopo importa. Avaliar apenas a interface pode esconder falhas na API — e é justamente nelas que boa parte dos vazamentos acontece hoje.

Quando o produto tem web, mobile e API, o ideal é tratar a API como parte central do escopo, porque é o ponto por onde tudo passa.

Autorização, ética e LGPD

Pentest só pode ser feito com autorização explícita e por escrito do responsável pelo sistema. Os ativos, as técnicas e os limites de impacto são combinados antes de começar, para evitar indisponibilidade e responsabilidade indevida.

Ao lidar com dados pessoais, o trabalho segue princípios de minimização e sigilo, alinhados à LGPD. Trabalhamos por padrão com dados mascarados ou de teste, e o material produzido — relatórios e evidências — pertence ao cliente.

Erros comuns ao contratar um pentest

Muitos projetos falham não por falta de ferramenta, mas por escopo mal definido ou entregável difícil de usar. Um bom pentest precisa ser executável pelo seu time.

E vale lembrar: pentest é um retrato do momento. Sem corrigir e reavaliar, o ganho de segurança se perde com o tempo.

• ✓ Contratar sem escopo escrito ou sem autorização formal.
• ✓ Confundir scanner automático com pentest manual.
• ✓ Receber um relatório que o time não consegue reproduzir.
• ✓ Não priorizar por risco e tentar corrigir tudo de uma vez.
• ✓ Não fazer reteste depois das correções.

Checklist rápido antes de contratar

Use esta lista para comparar propostas e evitar a armadilha de contratar apenas pelo menor preço sem olhar o que está de fato incluído. Uma proposta barata com escopo vago costuma sair caro.

O que importa é o escopo real, o formato do entregável e o que acontece depois do teste — se há reteste e como o seu time é apoiado na correção.

• ✓ Escopo e autorização definidos por escrito?
• ✓ A metodologia segue referência reconhecida (OWASP)?
• ✓ O relatório é reproduzível, com evidências?
• ✓ As recomendações são priorizadas por risco?
• ✓ O reteste está previsto, mesmo que contratado à parte?

Perguntas frequentes