Testes de intrusão a APIs: guia pelo OWASP API Security Top 10 e definição do âmbito
Como funciona um teste de intrusão a APIs (REST, GraphQL, gRPC): o OWASP API Security Top 10 como mapa de cobertura, como delimitar o âmbito e o que esperar do relatório.
Resumo: um teste de intrusão a APIs foca as interfaces que o seu frontend, a sua app mobile e os seus parceiros consomem — REST, GraphQL, gRPC e webhooks. A referência de cobertura é o OWASP API Security Top 10 (2023), liderado por falhas de autorização que os scanners não detetam. Um bom teste é grey box: com especificação OpenAPI, contas por perfil e pelo menos dois utilizadores por papel.
Em produtos modernos, a API é o produto. Qualquer controlo que exista só na interface pode ser contornado por quem chama a API diretamente — por isso o teste de API é hoje o de maior retorno para a maioria das empresas de software.
O OWASP API Security Top 10 (2023) como mapa de cobertura
| ID | Risco | O que significa para o seu negócio |
|---|---|---|
| API1 | Broken Object Level Authorization (BOLA) | um cliente acede aos dados de outro trocando um identificador |
| API2 | Broken Authentication | sessões, tokens ou recuperação de palavra-passe permitem tomar contas |
| API3 | Broken Object Property Level Authorization | campos que o utilizador não devia ver ou alterar |
| API4 | Unrestricted Resource Consumption | custos e indisponibilidade por falta de limites |
| API5 | Broken Function Level Authorization | funções de administração acessíveis a utilizadores comuns |
| API6 | Unrestricted Access to Sensitive Business Flows | automação abusiva de compras, cupões, registos |
| API7 | Server-Side Request Forgery | o servidor é levado a aceder a recursos internos |
| API8 | Security Misconfiguration | CORS, cabeçalhos, mensagens de erro, configurações por omissão |
| API9 | Improper Inventory Management | versões antigas e endpoints esquecidos ainda ativos |
| API10 | Unsafe Consumption of APIs | confiança excessiva em dados de APIs de terceiros |
Quatro dos dez itens (API1, API3, API5, API6) são sobre autorização e lógica de negócio — a ferramenta não sabe o que é "seu" e o que é "do outro". Veja o campeão da lista em BOLA/IDOR em APIs e os erros de autenticação mais comuns em JWT e OAuth.
Como delimitar o âmbito
O esforço depende menos do número de endpoints e mais de quantas combinações objeto × utilizador × operação é preciso verificar. Levante:
- Especificação: OpenAPI/Swagger, schema GraphQL, ficheiros .proto, coleção do Postman.
- Perfis e tenants: que papéis existem e se há multi-tenant.
- Fluxos críticos: pagamentos, transferências, exportação de dados, convites, alteração de e-mail e palavra-passe.
- Autenticação: sessão, JWT, OAuth/OIDC, chaves de API, mTLS.
- Versões: a v1 ainda está ativa? Há endpoints internos expostos pelo mesmo gateway?
- Ambiente: staging com dados realistas ou produção com janela definida.
Uma API de até ~80 endpoints com 2–4 perfis leva tipicamente 5 a 12 dias de teste; veja quanto custa um teste de intrusão.
O que entregar à equipa de teste
- Especificação atualizada, incluindo endpoints "internos".
- Pelo menos duas contas por perfil, em pelo menos dois tenants quando aplicável.
- Dados de exemplo nos fluxos críticos.
- IPs da equipa autorizados na WAF/rate limit de staging.
- Um contacto técnico para dúvidas rápidas e alertas de achados críticos.
O que esperar do resultado
- Achados com prova de conceito reproduzível, severidade justificada e impacto de negócio.
- Cadeias de ataque, não itens isolados.
- Recomendações ao nível do código e da arquitetura: autorização centralizada por objeto, filtragem na consulta à base de dados, listas de campos permitidos na serialização, limites por utilizador e por fluxo.
- Reteste após as correções.
Como prevenir entre testes
- Testes automáticos de autorização na CI.
- Inventário vivo de APIs, com data de desativação para versões antigas.
- Rate limit por utilizador e por fluxo de negócio, não só por IP.
- Revisão de segurança em cada alteração do modelo de dados ou de perfis.
Perguntas frequentes
Qual a diferença entre testar a API e testar a aplicação web?
O teste web cobre a aplicação vista pelo navegador; o de API foca as interfaces chamadas diretamente, incluindo as usadas por apps e parceiros. Em SPAs modernas sobrepõem-se, e o âmbito ideal testa as duas camadas.
Tenho de fornecer a documentação da API?
Não é obrigatório, mas é muito recomendado: sem documentação, parte do orçamento vai para descoberta; com ela, vai para o ataque.
O teste pode ser feito em produção?
Pode, com janela, limites de carga e regras claras para operações que alteram dados. Sempre que possível, preferimos um staging fiel à produção.
GraphQL é diferente?
As classes de risco são as mesmas, mas a superfície muda — introspeção, consultas aninhadas, batching e resolvers com regras de autorização próprias exigem técnica específica.