As APIs são a espinha dorsal dos aplicativos modernos — e a superfície mais atacada.Mais de 80% do tráfego da web agora flui através de APIs, e os ataques API aumentaram 700% nos últimos anos. O teste de segurança API não é mais opcional – é essencial para qualquer organização que expõe APIs a parceiros, aplicativos móveis ou à Internet.
Principais conclusões
- APIs têm vulnerabilidades únicas:O OWASP API Security Top 10 cobre ameaças específicas para APIs que os testes tradicionais da web não percebem.
- Autorização em nível de objeto quebrado (BOLA) é o risco API nº 1:Os invasores manipulam IDs de objetos em solicitações API para acessar dados de outros usuários.
- As lacunas de autenticação e limitação de taxa são generalizadas:Muitas APIs carecem de validação de token adequada, limitação de taxa e prevenção de abuso.
- Testes automatizados + manuais são necessários:Scanners automatizados encontram falhas comuns de API. O teste manual encontra vulnerabilidades de lógica de negócios e desvios de autorização complexos.
OWASP API Top 10 de segurança (2023)
| # | Vulnerabilidade | Descrição | Abordagem de teste |
|---|---|---|---|
| API1 | Autorização em nível de objeto quebrado | Acessando objetos de outros usuários alterando IDs | Teste cada endpoint com diferentes tokens de usuário, enumere IDs de objetos |
| API2 | Autenticação quebrada | Geração fraca de tokens, validação ausente, fluxos inseguros | Análise de token, força bruta, manipulação de fluxo |
| API3 | Autorização em nível de propriedade de objeto quebrado | Atribuição em massa, exposição excessiva de dados nas respostas | Adicione campos inesperados nas solicitações, analise os dados de resposta |
| API4 | Consumo irrestrito de recursos | Limites de taxa, paginação ou tamanho ausentes | Testes de inundação, testes de carga útil grande, desvio de paginação |
| API5 | Autorização de nível de função quebrada | Acessando endpoints administrativos como usuário normal | Teste endpoints administrativos com tokens não administrativos |
| API6 | Acesso irrestrito a fluxos comerciais sensíveis | Abuso automatizado de funcionalidades empresariais | Simulação de bot, teste de fluxo automatizado |
| API7 | Falsificação de solicitação no lado do servidor (SSRF) | API busca URLs controladas pelo invasor | Manipulação de parâmetros de URL, sondagem de rede interna |
| API8 | Configuração incorreta de segurança | Erros detalhados, configuração incorreta do CORS, métodos desnecessários | Verificação de configuração, análise de cabeçalho |
| API9 | Gestão inadequada de estoque | Endpoints obsoletos, não documentados ou shadow API | API descoberta, comparação de documentação |
| API10 | Consumo inseguro de APIs | Confiar em respostas API de terceiros sem validação | Manipulação de resposta, falsificação upstream de API |
API Metodologia de testes de segurança
Descoberta e revisão da documentação
Comece mapeando todos os endpoints API. Compare a documentação API (especificações OpenAPI/Swagger) com o comportamento real. Use ferramentas como Burp Suite, Postman e scripts personalizados para descobrir endpoints não documentados. Shadow APIs – endpoints que existem, mas não estão documentados – são comuns e muitas vezes não possuem controles de segurança porque foram esquecidos.
Teste de autenticação
Teste os mecanismos de autenticação API: validação de token JWT (os tokens podem ser manipulados, forjados ou reproduzidos?), fluxos OAuth (o parâmetro de estado é aplicado? Os URIs de redirecionamento podem ser manipulados?), gerenciamento de chaves API (as chaves têm escopo adequado? Elas podem ser extraídas do código do lado do cliente?) e gerenciamento de sessão (os tokens expiram? Eles podem ser revogados?).
Testes de autorização
Teste cada endpoint com diferentes níveis de privilégio. Substitua IDs de usuário, IDs de locatário e IDs de objeto em solicitações para verificar controles de acesso. Teste a autorização horizontal (usuário A acessando os dados do usuário B) e autorização vertical (usuário normal acessando endpoints administrativos). Use a automação para testar todos os endpoints de forma sistemática: apenas o teste manual erra endpoints em APIs grandes.
Validação de entradas e testes de injeção
Teste todos os parâmetros de entrada para vulnerabilidades de injeção: injeção SQL em parâmetros de consulta, injeção NoSQL em corpos JSON, injeção de comando em endpoints de processamento e injeção específica de GraphQL (consultas aninhadas, abuso de introspecção). Teste com entradas malformadas (fuzzing) e cargas cuidadosamente elaboradas visando tipos de injeção específicos.
API Ferramentas de teste de segurança
- Suíte Burp:Testes de segurança API abrangentes com recursos de proxy, scanner e automação.
- Carteiro:Plataforma de desenvolvimento API com coleções de testes de segurança e scripts de testes automatizados.
- ZAP OWASP:Scanner de segurança API gratuito com importação OpenAPI e verificação automatizada.
- Núcleos:Scanner baseado em modelo com modelos específicos de API para vulnerabilidades comuns.
- Arjun:Ferramenta de descoberta de parâmetros HTTP para encontrar parâmetros API ocultos.
- GraphQL Viajante:GraphQL API ferramenta de visualização e introspecção.
Como Opsio testa a segurança de API
- OWASP API Cobertura dos 10 principais:Cada teste API cobre todas as 10 categorias com técnicas de teste específicas da plataforma.
- Abordagem automatizada + manual:Verificação automatizada de vulnerabilidades conhecidas, testes manuais de lógica de negócios e falhas de autorização complexas.
- Especialização em GraphQL:Testes especializados para APIs GraphQL, incluindo introspecção, ataques de consultas aninhadas e abuso de consultas em lote.
- Integração CI/CD:Ajudamos a integrar testes de segurança automatizados API em seu pipeline de implantação para garantia contínua.
Perguntas Frequentes
Qual a diferença entre os testes de segurança API e os testes de aplicativos da web?
O teste de aplicativos da Web concentra-se na interface do usuário e nas interações baseadas no navegador. O teste API visa diretamente a camada API – testando endpoints, parâmetros, tokens de autenticação e serialização de dados que a UI pode não expor. Muitas vulnerabilidades existem apenas na camada API e não podem ser descobertas apenas por meio de testes de IU.
Devo testar APIs internas ou apenas aquelas voltadas ao público?
Ambos. APIs públicas estão diretamente expostas a invasores e devem ser testadas primeiro. As APIs internas costumam ser menos seguras porque os desenvolvedores assumem proteção no nível da rede. Se um invasor obtiver acesso interno (por meio de phishing, comprometimento VPN ou configuração incorreta da nuvem), as APIs internas se tornarão a superfície de ataque para movimentação lateral e roubo de dados.
Como posso proteger APIs GraphQL especificamente?
GraphQL introduz riscos únicos: profundidade de consulta irrestrita (negação de serviço), divulgação de introspecção (vazamento de esquema) e abuso de consulta em lote (contornando limites de taxa). Proteja o GraphQL desativando a introspecção na produção, implementando limites de profundidade e complexidade da consulta, aplicando autorização por campo e limitando a taxa pelo custo da consulta em vez da contagem de solicitações.