Testes penetracao em APIs: checklist de 12 itens

Testes de penetracao em APIs nao se resumem a rodar um scanner contra o endpoint. A API expoe logica de negocio, identidade e dados de terceiros, entao o checklist precisa ser verificavel item a item. Use esta lista antes de releases criticos, mudancas de contrato ou apos incidentes. Segundo a Wikipedia, o teste de intrusao simula um ataque de fonte maliciosa para avaliar a seguranca de um sistema ou rede (Wikipedia, 2026-09-16).

Autenticacao e gestao de sessao

1. Tokens expiram e sao revogaveis. Verifique o TTL real do access token e se o refresh token pode ser invalidado no servidor. Token sem revogacao transforma vazamento em acesso permanente.

2. Nenhuma credencial em URL ou log. Chaves em query string ficam registradas em proxies, historico e APM. Confirme que o header Authorization e o unico canal aceito.

3. Fluxo de recuperacao de senha resiste a enumeracao. Respostas identicas para email existente e inexistente. Um teste com duas contas reais revela a diferenca em segundos.

Autorizacao e controle de acesso

4. IDOR por objeto e por funcao. Troque o ID do recurso por outro de usuario distinto e verifique o retorno. Depois tente acessar funcao administrativa com token comum.

5. Escopo de token respeitado. Token emitido para leitura nao deve executar escrita. Teste cada scope declarado isoladamente.

6. Multi-tenant isolado. Em APIs SaaS, um tenant nunca enxerga dado de outro. Esse e o item que mais aparece em relatorios de bug bounty.

Validacao de entrada

7. Injecao em todos os parametros. SQL, NoSQL, comandos e template. Inclua headers, path params e campos de metadata, nao so o body JSON.

8. Mass assignment bloqueado. Envie campos nao documentados (role, is_admin, tenant_id) e confirme que sao ignorados.

9. Deserializacao segura. Se a API aceita XML ou formatos binarios, teste entidades externas e payloads grandes.

Rate limiting, logging e erros

10. Limite por identidade, nao so por IP. Limite por IP falha atras de NAT corporativo e nao protege contra abuso autenticado.

11. Logs registram tentativas negadas. Sem isso, um ataque em andamento passa invisivel. Verifique se 401, 403 e 429 geram evento com correlation ID.

12. Mensagens de erro nao vazam stack. Retorne codigo e mensagem generica. Stack trace em producao entrega versao de framework e caminho de arquivo.

O erro mais comum

Times tratam o pentest de API como evento anual. A API muda toda semana, o contrato muda, o endpoint novo entra sem revisao. O checklist perde valor se nao rodar a cada release que altera autenticacao, autorizacao ou schema. Automatize os itens 4, 7 e 10 em CI e reserve o teste manual para os que exigem raciocinio de negocio.

FAQ

Teste de penetracao em API e diferente de scan automatizado?

Sim. O scanner cobre padroes conhecidos, como headers ausentes e injecao basica. O pentest avalia logica de negocio, encadeamento de falhas e cenarios de autorizacao que exigem contexto do dominio.

Com que frequencia rodar o checklist?

Antes de cada release que altere autenticacao, autorizacao ou schema, e no minimo uma vez por trimestre para os demais itens. APIs com exposicao publica pedem cadencia maior.

Preciso de ambiente separado para o pentest?

Sim. Rodar em producao pode corromper dados e disparar alertas falsos. Use ambiente espelho com dados sinteticos que preservem os relacionamentos entre entidades.

O checklist substitui o OWASP API Top 10?

Nao. O checklist operacionaliza os itens do OWASP API Top 10 em verificacoes executaveis. Use os dois juntos: a lista como referencia, o checklist como rotina.

Como priorizar quando o time e pequeno?

Comece pelos itens 4, 5 e 10. Falhas de autorizacao e ausencia de rate limiting concentram o maior risco pratico em APIs autenticadas.

Pentest de API exige contratar empresa externa?

Nao necessariamente. Times internos rodam os itens de validacao de entrada e logging. Testes de autorizacao com visao externa tendem a encontrar falhas que o proprio time normaliza.