Pentest White Box em 2026: o que é, o que encontra e quando contratar (guia para SaaS e fintech)

Pentest White Box — ou “caixa-branca” — é o pentest em que o pesquisador de segurança recebe acesso ao código-fonte, à documentação da arquitetura e às pessoas do time, além das contas de teste. Ele lê o código procurando caminhos de ataque e confirma cada suspeita explorando a aplicação rodando. É a modalidade de maior profundidade: enxerga falhas que, de fora, levariam semanas para aparecer — ou nunca apareceriam.

Este guia fecha a série sobre as três modalidades de pentest. Aqui você vê o que o White Box encontra que os outros não encontram (com exemplos de código vulnerável e corrigido), como funciona na prática, quando vale a pena, quando não vale e quanto custa.

O que é pentest White Box, em uma definição

Pentest White Box é a simulação de ataque feita por alguém que conhece o sistema por dentro — o código, as regras de negócio, a infraestrutura e as integrações. Em vez de descobrir a aplicação por tentativa e erro, como no Black Box, o pesquisador usa o código como mapa: identifica onde estão as decisões de segurança (quem pode ver o quê, como o dinheiro se move, de onde vêm os dados) e testa se cada uma resiste a um atacante.

O próprio OWASP defende essa abordagem. No ASVS 4.0.3 (o padrão de verificação de segurança de aplicações), o nível 1 é descrito como o único totalmente testável sem acesso ao código; os níveis 2 e 3 exigem acesso a documentação, código-fonte, configuração e às pessoas envolvidas no desenvolvimento. O documento recomenda, inclusive, trocar testes puramente externos por pentests guiados pelo código.

White Box × Grey Box × Black Box

As três modalidades respondem a perguntas diferentes:

Os detalhes das outras duas estão em Pentest Black Box e Pentest Grey Box.

O que o White Box encontra que os outros não encontram

Os exemplos abaixo são padrões recorrentes em SaaS e fintech. Em todos, o teste de fora até pode chegar à falha — mas depende de sorte, de muitas tentativas ou de a rota estar visível na interface. Lendo o código, ela aparece de uma vez, junto com todas as variantes.

1. Endpoint sem checagem de autorização (CWE-639)

O endpoint confia no identificador que vem na URL e não confere se o recurso pertence a quem está pedindo — o famoso BOLA/IDOR. De fora, achar isso exige duas contas e adivinhar identificadores. No código, o pesquisador vê todas as rotas que consultam o banco sem filtrar pelo tenant, inclusive as que nenhuma tela chama.

// Vulnerável: busca a fatura só pelo id da URL
app.get("/api/invoices/:id", auth, async (req, res) => {
  const invoice = await db.invoice.findUnique({ where: { id: req.params.id } });
  res.json(invoice);
});

// Correto: o filtro inclui o tenant de quem está autenticado
app.get("/api/invoices/:id", auth, async (req, res) => {
  const invoice = await db.invoice.findFirst({
    where: { id: req.params.id, tenantId: req.user.tenantId },
  });
  if (!invoice) return res.sendStatus(404);
  res.json(invoice);
});

Referência: CWE-639 — Authorization Bypass Through User-Controlled Key.

2. Segredos no código e no histórico do Git (CWE-798)

Chave de API de pagamento, senha de banco, token de serviço de e-mail. Mesmo quando o time apaga do código, o segredo continua no histórico do repositório — e em qualquer cópia dele. Um teste externo raramente chega lá; a revisão de código encontra, e a correção inclui trocar (rotacionar) a chave, não só apagar a linha.

// Vulnerável: a chave fica no código e no histórico do Git
const stripe = new Stripe("sk_live_XXXXXXXXXXXX");

// Correto: segredo em variável de ambiente ou cofre, com rotação
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);

Referência: CWE-798 — Use of Hard-coded Credentials.

3. Token previsível (CWE-330)

Link de redefinição de senha, convite, confirmação de e-mail: se o token é gerado com uma função que não é criptograficamente segura, ele pode ser previsto. De fora, isso é quase invisível — o token parece aleatório. No código, é uma linha.

// Vulnerável: Math.random não serve para segredo
const resetToken = Math.random().toString(36).slice(2);

// Correto: gerador criptográfico
import { randomBytes } from "node:crypto";
const resetToken = randomBytes(32).toString("hex");

Referência: CWE-330 — Use of Insufficiently Random Values.

4. Desserialização de dado externo (CWE-502)

Quando a aplicação reconstrói objetos a partir de dados que vêm de fora (cookie, fila, cache, upload) usando um formato que permite executar código, o resultado pode ser execução remota no servidor. O ponto vulnerável costuma estar longe da tela — numa integração ou num worker — e é exatamente o tipo de coisa que a leitura do código revela. A correção é usar formatos sem execução de código (como JSON), validar o conteúdo e assinar o que precisa voltar íntegro. Referência: CWE-502 — Deserialization of Untrusted Data.

5. Rotas esquecidas e lógica escondida

Endpoint de debug que ficou em produção, rota da versão antiga da API, feature flag que libera função de administrador, job interno que aceita chamada externa. Nada disso aparece na interface — e por isso passa batido em Black Box e, muitas vezes, em Grey Box. Com o código, o pesquisador lista todas as rotas registradas e testa cada uma.

6. Dependência vulnerável que é realmente usada

Ferramentas de dependências listam dezenas de bibliotecas com CVE. O que importa é se o trecho vulnerável é chamado pelo seu código, com dado que o atacante controla. A revisão White Box responde isso — e transforma uma lista longa em poucos itens que exigem ação de verdade.

Como funciona na prática

1. Escopo e acesso. Define-se o que entra (repositórios, módulos, ambiente de teste, contas) e uma versão fixa do código, para que os achados tenham arquivo e linha estáveis.
2. Mapa da arquitetura e dos fluxos críticos. Autenticação, autorização, movimentação de dinheiro, dados pessoais e integrações com terceiros — é onde o risco se concentra.
3. Revisão guiada por risco. Não é ler cada linha do sistema: é seguir os caminhos que um atacante usaria, das entradas externas até as decisões de segurança.
4. Validação na aplicação rodando. Cada suspeita vira teste real. Só entra no relatório o que tem prova de exploração (ou justificativa técnica clara).
5. Relatório e reteste. Cada achado com arquivo e linha, impacto, passo a passo para reproduzir e correção sugerida; depois das correções, reteste.

Por que não é só rodar uma ferramenta de SAST

Ferramentas de análise estática (SAST) são úteis no dia a dia, dentro do pipeline de CI. Mas elas apontam padrões, não ataques: geram falsos positivos, não entendem regra de negócio (“o usuário do plano grátis não pode exportar relatórios”) e não sabem se um trecho é alcançável por um atacante. No pentest White Box, ferramenta é apoio — quem decide o que é falha, e prova, é o pesquisador. O OWASP Code Review Guide é uma boa referência sobre essa combinação de revisão manual e ferramentas.

Quando contratar White Box

1. Fintech e pagamentos

Fluxos de dinheiro têm pouco espaço para erro. Para quem processa cartão, o PCI DSS v4.0 (requisito 6.2.3) pede que o software desenvolvido internamente seja revisado antes de ir para produção, para encontrar e corrigir vulnerabilidades de código. O texto oficial está na biblioteca de documentos do PCI SSC. Para o contexto regulatório brasileiro, veja pentest para fintech e pentest para meios de pagamento.

2. Módulos críticos novos ou reescritos

Autenticação, permissões, billing, carteira, Pix, motor de regras: quando um desses módulos nasce ou muda muito, revisar o código antes do lançamento é bem mais barato do que descobrir a falha em produção.

3. Due diligence, cliente enterprise ou auditoria

Investidores, compradores e clientes grandes cada vez mais pedem evidência de testes de segurança. Um relatório White Box, com escopo e metodologia claros, é uma evidência forte — sem prometer certificação, que depende do auditor e do framework escolhido.

4. Depois de um incidente

Corrigir o ponto explorado não basta: a mesma falha costuma existir em outros lugares do código. A revisão White Box encontra as variantes e a causa raiz.

5. Código herdado ou terceirizado

Sistema comprado, time que mudou, fornecedor que entregou e saiu. Antes de assumir o risco, vale saber o que está lá dentro.

Quando não é a melhor escolha

• Quando a pergunta é “o que um atacante de fora vê?” — para validar superfície exposta, Black Box responde melhor e mais rápido.
• Quando o orçamento é curto e a aplicação é grande — um Grey Box bem focado em autorização e lógica de negócio costuma dar mais retorno por hora.
• Quando não há acesso ao código — por exemplo, um SaaS de terceiros que você usa. Aí o teste possível é Black ou Grey Box, dentro das regras do fornecedor.

O que exigir de quem vai ver seu código

Entregar o código é entregar o mapa do sistema. Antes de liberar o acesso, exija: NDA assinado antes de qualquer acesso; acesso somente leitura e por tempo limitado; nada de cópia fora do ambiente combinado; e descarte comprovado ao fim do projeto. Uma empresa séria aceita essas condições sem discussão.

Quanto custa um pentest White Box

Na No Vuln, o pentest é contratado por horas, com valor-hora de R$ 350 a R$ 500 por hora. Como o White Box inclui leitura de código além dos testes, ele costuma usar pacotes maiores: o Deep Dive (50h), de R$ 17.500 a R$ 25.000, para um produto ou módulo crítico, e o Full Scope (100h+), a partir de R$ 35.000, para sistemas maiores ou várias aplicações. O que define as horas é o tamanho do código em escopo e o número de fluxos críticos.

Para comparar com o mercado, veja quanto custa um pentest no Brasil e o custo por porte de SaaS B2B.

Como combinar White Box com Grey Box e Black Box

As modalidades se complementam. Uma combinação comum em SaaS e fintech maduros: White Box nos módulos críticos e a cada mudança grande de arquitetura; Grey Box como teste recorrente da aplicação inteira; Black Box para acompanhar a superfície exposta entre um ciclo e outro. Assim o orçamento vai para profundidade onde o risco é maior, sem deixar o resto descoberto.

O que fazer agora

1. Liste os módulos onde uma falha custaria mais caro (dinheiro, dados pessoais, permissões).
2. Veja quando foi a última vez que alguém de fora leu esse código com olhar de atacante.
3. Confira se há segredos no repositório e no histórico — e troque os que estiverem lá.
4. Coloque SAST e verificação de dependências no CI, como rede de proteção contínua.
5. Para os módulos críticos, planeje um pentest White Box antes da próxima grande entrega.

Para o escopo técnico de pentest em SaaS, veja pentest para SaaS. Se quiser conversar sobre o seu caso: fale com um pesquisador — NDA bilateral antes da primeira call técnica.