A maioria dos sistemas modernos tem um frontend bem construído, com autenticação, validações e proteções visíveis. Mas por trás existe uma API que qualquer um pode chamar diretamente, sem passar pelo frontend e, muitas vezes, sem as mesmas proteções.
É o cenário mais comum nos pentests de API que realizamos: as vulnerabilidades não estão na interface, estão nos endpoints.
Por Que APIs São Alvos Críticos
APIs expõem diretamente a lógica de negócio. Uma falha em um endpoint pode dar acesso a dados de todos os usuários, permitir operações sem autorização ou vazar informações que nunca deveriam ser públicas. E, ao contrário de uma tela, a API não esconde nada de quem inspeciona o tráfego: cada campo da resposta fica visível no navegador ou no aplicativo.
OWASP API Security Top 10 (edição 2023)
O OWASP API Security Top 10 lista as falhas mais comuns em APIs. Na edição atual:
- Autorização quebrada no nível do objeto (BOLA): um usuário acessa dados de outro trocando um ID na requisição. Exemplo:
/api/pedidos/12345, e o 12345 não precisa ser um pedido seu. - Autenticação quebrada: tokens sem expiração, sem revogação ou aceitos mesmo após o logout, recuperação de senha frágil.
- Autorização quebrada no nível da propriedade: a API devolve campos que o usuário não deveria ver (a resposta traz 40 campos, a tela mostra 5) ou aceita alterar campos que ele não deveria mudar, como o perfil ou o preço.
- Consumo de recursos sem limite: sem limite de requisições, de tamanho ou de custo por chamada, força bruta, enumeração e abuso de serviços pagos, como envio de SMS, ficam triviais.
- Autorização quebrada no nível da função: um usuário comum chama endpoints administrativos porque a API só esconde o botão, mas não verifica o perfil.
- Acesso irrestrito a fluxos de negócio sensíveis: automação de compra de ingressos, criação de contas em massa, uso abusivo de cupons. Nada quebra tecnicamente, mas o negócio sofre.
- SSRF (Server-Side Request Forgery): endpoints que buscam URLs informadas pelo usuário podem ser usados para alcançar sistemas internos ou a metadata da nuvem.
- Configuração de segurança incorreta: CORS permissivo, mensagens de erro detalhadas, métodos HTTP desnecessários habilitados.
- Gestão inadequada do inventário: versões antigas da API (
/v1) e ambientes de teste esquecidos no ar, sem as correções da versão atual. - Consumo inseguro de APIs de terceiros: confiar sem validação no que vem de integrações e parceiros.
Repare que quase todas são falhas de autorização e de lógica. Scanners automáticos não sabem que o pedido 12345 é de outro cliente, por isso elas só aparecem em teste manual.
Como Funciona um Pentest de API
O processo começa com o mapeamento dos endpoints, a partir da documentação (Swagger/OpenAPI ou coleção do Postman), do tráfego do aplicativo ou de enumeração. Depois:
- Testamos autenticação e autorização em cada endpoint, com usuários de perfis diferentes.
- Verificamos o que cada resposta expõe além do necessário.
- Testamos manipulação de parâmetros (BOLA, alteração de propriedades protegidas).
- Avaliamos limites de requisição e controles contra automação.
- Testamos injeção nos campos aceitos pela API.
- Procuramos versões antigas, ambientes de teste e endpoints não documentados.
GraphQL Tem Riscos Próprios
APIs GraphQL concentram tudo em um único endpoint, o que muda o teste. Os pontos que mais aparecem: introspecção ligada em produção, que entrega o mapa completo da API; consultas aninhadas sem limite de profundidade ou custo, que derrubam o servidor; agrupamento de várias operações em uma requisição, que contorna limites de tentativa de login; e autorização verificada só no resolver principal, e não nos campos relacionados.
O Que Preparar Antes do Teste
- Documentação atualizada da API (OpenAPI ou coleção do Postman), quando houver.
- Pelo menos dois usuários de cada perfil, para testar se um consegue ver ou alterar dados do outro.
- Um ambiente de homologação parecido com produção, com dados fictícios.
- Os fluxos críticos do negócio descritos em poucas linhas: pagamento, cadastro, troca de senha, aprovação.
Quem Precisa de Pentest em APIs?
Qualquer sistema que exponha uma API para uso externo: aplicativos mobile, integrações B2B, sistemas SaaS, e-commerce com checkout próprio. Se terceiros ou usuários finais consomem sua API diretamente, ela precisa ser testada, de preferência antes de cada mudança grande e pelo menos uma vez por ano.
APIs internas (microsserviços) também são alvo: se um serviço interno for comprometido, o atacante pode se mover lateralmente pela infraestrutura. E, se a API sustenta um aplicativo, o teste costuma ser feito junto com o pentest mobile.
Perguntas Frequentes
Pentest de API é diferente de pentest web?
Os dois se sobrepõem, mas o foco muda. O pentest web olha a aplicação como o usuário a vê, incluindo o navegador. O pentest de API vai direto aos endpoints, com mais ênfase em autorização, lógica de negócio e exposição de dados, inclusive em chamadas que nenhuma tela usa.
Um scanner de API não resolve?
Scanners ajudam a achar configuração errada e falhas conhecidas, mas não entendem regra de negócio. Saber que um usuário não deveria ver o pedido de outro, ou que um cupom não deveria ser usado cem vezes, exige um teste manual.