Pentest em aplicações web e APIs

A varredura é automática. Uma ferramenta compara versões e respostas do sistema com uma base de falhas conhecidas e gera uma lista de possíveis problemas, com muitos falsos positivos. No pentest, uma pessoa tenta explorar cada falha para comprovar o impacto e investiga o que nenhuma ferramenta enxerga, como um usuário que acessa dados de outra empresa ao trocar um identificador ou uma etapa de pagamento que pode ser pulada. A varredura pode rodar com frequência; o pentest aprofunda a análise em intervalos maiores.

A prática mais comum é um teste por ano e outro sempre que houver mudança significativa, como um módulo novo, uma troca de infraestrutura ou uma integração de pagamento. Algumas normas fixam esse mínimo. O PCI DSS pede pentest interno e externo pelo menos a cada 12 meses e após mudança significativa. A Resolução CMN nº 4.893/2021, alterada pela Resolução CMN nº 5.274/2025, exige teste de intrusão no mínimo anual das instituições autorizadas pelo Banco Central, feito com independência.

Os limites são definidos antes, por escrito. Testes que podem afetar a disponibilidade, como carga ou exploração destrutiva, só rodam em homologação ou em janela autorizada. Em produção usamos contas de teste e técnicas que não alteram dado real. Quando é preciso confirmar uma escrita, a operação é feita de forma que possa ser desfeita.

Depende de quanto a homologação se parece com produção. Se o ambiente de testes tem a mesma versão, a mesma configuração e dados fictícios equivalentes, ele é o lugar mais seguro para os testes mais agressivos. Muitas falhas, porém, estão na configuração de produção, como cabeçalhos, buckets e variáveis de ambiente. Por isso é comum combinar os dois: exploração em homologação e verificação controlada de configuração em produção.

Os endereços do sistema, contas de teste para cada perfil (no gray box, de pelo menos duas empresas ou clientes diferentes), a janela autorizada e um contato técnico para imprevistos. Convém avisar a equipe de infraestrutura e o provedor de hospedagem, para que o tráfego do teste não seja bloqueado como ataque real no meio do trabalho. No white box, acrescenta-se acesso de leitura ao repositório.

Depende do tamanho do sistema, do número de perfis de acesso e da modalidade. Uma aplicação com poucas dezenas de rotas é bem diferente de uma plataforma com centenas de endpoints e integrações. O prazo fica fechado na proposta, depois da conversa de escopo.

Uma falha crítica, como vazamento de dados entre clientes ou acesso administrativo sem senha, é comunicada ao contato técnico assim que confirmada, sem esperar o relatório final. O restante segue para o relatório, com severidade, evidência e orientação de correção. Depois das correções, fazemos o reteste e emitimos a versão final com o status de cada item.

O acordo de confidencialidade é assinado antes de qualquer acesso. O relatório circula só entre as pessoas indicadas pela empresa, e os dados vistos durante o teste servem apenas para comprovar a falha. Ao fim do contrato, as evidências que contenham dados reais são eliminadas, e fica guardado apenas o relatório final. Para apresentar a clientes e auditores, entregamos uma carta de execução que atesta o teste sem expor as vulnerabilidades.

Se contratado, sim. Como também desenvolvemos sistemas, podemos aplicar a correção direto no código, em branch separada e com revisão da sua equipe. Se preferir que a sua equipe corrija, o relatório traz a orientação e fazemos o reteste depois.