APIs mudam de framework, de linguagem e de arquitetura, mas os achados que mais aparecem em pentest continuam praticamente os mesmos há anos. Não é falta de ferramenta boa — é que esses padrões nascem de decisão de design, não de bug pontual, e por isso se repetem de projeto em projeto. Este é um panorama direto dos cinco que mais aparecem, na ordem em que costumam ser mais explorados.
1. Broken Object Level Authorization (BOLA)
É o achado mais comum em pentest de API, de longe. A rota autentica o usuário corretamente, mas não confere se aquele usuário tem permissão sobre o objeto específico que ele está pedindo. Trocar um ID numérico ou um UUID na URL e conseguir ver ou alterar dado de outra conta é o sintoma clássico. Acontece porque a checagem de autorização geralmente fica espalhada em vários endpoints, e é fácil esquecer um.
2. Exposição excessiva de dados
A API devolve o objeto inteiro do banco e deixa o front-end decidir o que mostrar. Funciona até alguém inspecionar a resposta bruta e encontrar campo de senha com hash, token interno, CPF ou dado de outro usuário que nunca deveria ter saído do backend. É um dos achados mais fáceis de confirmar e, ao mesmo tempo, mais fáceis de evitar: filtrar o retorno no servidor, nunca confiar que o cliente vai esconder o que não deveria ver.
3. Falta de rate limiting
Endpoint de login, de recuperação de senha ou de busca sem limite de tentativas abre caminho para força bruta, enumeração de usuários e abuso de custo (em APIs que chamam serviços pagos por requisição, como envio de SMS ou geração via IA). Rate limiting é barato de implementar e raramente prioridade — até aparecer num relatório de pentest.
4. Validação fraca de JWT
Token JWT aceito sem validar assinatura, aceitando o algoritmo 'none', ou validando a assinatura mas ignorando a expiração. Também aparece bastante token de vida longa demais sem mecanismo de revogação — se vazar, fica válido até expirar, não até alguém perceber.
- Assinatura sempre validada no servidor, nunca só decodificada
- Algoritmo fixado explicitamente, nunca lido do header do próprio token
- Expiração curta, com refresh token de vida mais longa e revogável
5. Mensagem de erro verbosa demais
Stack trace, versão de framework, query SQL ou caminho de arquivo no corpo de um erro 500 não compromete nada sozinho, mas encurta muito o caminho de quem está mapeando a superfície de ataque. É informação de reconhecimento de graça, oferecida pela própria aplicação.
Por que isso continua acontecendo
Nenhum desses cinco é sofisticado. Todos são bem documentados — quatro deles estão no OWASP API Security Top 10. O padrão que vemos é que scanner automatizado tradicional detecta bem o item 5 e razoavelmente o item 3, mas item 1, 2 e 4 dependem de entender a lógica de negócio da API — quem deveria ver o quê — e isso é exatamente o que separa um scan de um pentest.