Testes de Segurança de API: OWASP Top 10, Ferramentas e Checklist

Introdução

As APIs são o vetor de ataque mais comum em aplicações modernas. De acordo com o Gartner, os ataques a APIs tornaram-se o vetor de ataque mais frequente para aplicações web corporativas em 2024. Cada API que você expõe é um potencial ponto de entrada para atacantes, e os testes tradicionais de segurança de aplicações web não são suficientes para protegê-las.

Os testes de segurança de API são a prática de testar sistematicamente seus endpoints de API em busca de vulnerabilidades, desvios de autenticação, exposição de dados, ataques de injeção e falhas de lógica de negócios. Este guia abrange o OWASP API Security Top 10, técnicas práticas de teste com exemplos de código, as melhores ferramentas disponíveis e um checklist abrangente que você pode seguir.

Seja você um desenvolvedor criando APIs, um engenheiro de QA validando segurança ou um líder DevSecOps implementando segurança shift-left, este guia oferece técnicas acionáveis para proteger suas APIs.

OWASP API Security Top 10 (2023)

O OWASP API Security Top 10 é o framework padrão do setor para riscos de segurança de API. Veja cada vulnerabilidade com técnicas de teste:

API1: Autorização em Nível de Objeto Quebrada (BOLA)

A vulnerabilidade de API mais comum. Um atacante manipula IDs de objetos nas requisições para acessar dados de outros usuários.

Como testar:

# Faça login como Usuário A, obtenha seu recurso
curl -X GET https://api.example.com/users/101/orders \
  -H "Authorization: Bearer USER_A_TOKEN"
# Retorna os pedidos do Usuário A ✓
# Agora tente acessar o recurso do Usuário B com o token do Usuário A
curl -X GET https://api.example.com/users/102/orders 

-H "Authorization: Bearer USER_A_TOKEN"
# Deve retornar 403 Forbidden, não os pedidos do Usuário B

Correção: Sempre verifique se o usuário autenticado é proprietário (ou tem permissão para acessar) o recurso solicitado. Nunca dependa apenas de IDs fornecidos pelo cliente.

API2: Autenticação Quebrada

Mecanismos de autenticação fracos que permitem a atacantes comprometer tokens, chaves ou senhas.

O que testar:

• Você consegue acessar endpoints protegidos sem um token? (Deve retornar 401)
• A API aceita tokens expirados?
• Existe limite de taxa nas tentativas de login?
• Os tokens são invalidados no logout/mudança de senha?
• O token é armazenado com segurança (cookies HttpOnly, não localStorage)?

# Teste: Sem cabeçalho de autenticação
curl -X GET https://api.example.com/users/me
# Esperado: 401 Unauthorized
# Teste: Token expirado
curl -X GET https://api.example.com/users/me 

-H "Authorization: Bearer EXPIRED_TOKEN_HERE"
# Esperado: 401 Unauthorized
# Teste: Proteção contra força bruta (tentativas rápidas de login)
for i in {1..100}; do
curl -s -o /dev/null -w "%{http_code}\n" 

-X POST https://api.example.com/auth/login 

-d '{"email":"victim@example.com","password":"guess'$i'"}'
done
# Esperado: 429 Too Many Requests após algumas tentativas

API3: Autorização em Nível de Propriedade de Objeto Quebrada

A API expõe propriedades sensíveis de objetos que deveriam estar ocultas ou ser somente leitura.

Como testar:

# Teste: Um usuário comum pode definir campos exclusivos de admin?
curl -X PATCH https://api.example.com/users/101 \
  -H "Authorization: Bearer REGULAR_USER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"role": "admin", "isVerified": true}'
# Esperado: "role" e "isVerified" devem ser ignorados ou retornar 403

API4: Consumo Irrestrito de Recursos

A API não limita taxas de requisição, tamanhos de payload ou operações intensivas em recursos.

O que testar:

• Envie payloads muito grandes (corpo JSON de 100MB)
• Solicite tamanhos de página muito grandes (GET /users?limit=1000000)
• Acione operações custosas repetidamente
• Faça upload de arquivos excessivamente grandes

API5: Autorização em Nível de Função Quebrada

Usuários comuns conseguem acessar endpoints de API exclusivos de administradores.

# Teste: Acesse endpoints admin com token de usuário comum
curl -X GET https://api.example.com/admin/users \
  -H "Authorization: Bearer REGULAR_USER_TOKEN"
# Esperado: 403 Forbidden
curl -X DELETE https://api.example.com/admin/users/102 

-H "Authorization: Bearer REGULAR_USER_TOKEN"
# Esperado: 403 Forbidden

API6: Acesso Irrestrito a Fluxos de Negócios Sensíveis

Abuso automatizado de recursos legítimos do negócio, como scalping, spam e abuso de cupons.

API7: Server Side Request Forgery (SSRF)

A API busca URLs externas fornecidas pelo usuário sem validação, permitindo que atacantes escaneiem redes internas.

# Teste: Tente acessar serviços internos via parâmetro de URL
curl -X POST https://api.example.com/fetch-url \
  -d '{"url": "http://169.254.169.254/latest/meta-data/"}'
# Deve ser bloqueado, isto aponta para os metadados da AWS
curl -X POST https://api.example.com/fetch-url 

-d '{"url": "http://localhost:6379/"}'
# Deve ser bloqueado, isto aponta para o Redis interno

API8: Configuração de Segurança Incorreta

Ausência de cabeçalhos de segurança, mensagens de erro detalhadas, métodos HTTP desnecessários habilitados.

# Teste: Verifique os cabeçalhos de segurança
curl -I https://api.example.com/users
# Verifique se estes cabeçalhos estão presentes:
# X-Content-Type-Options: nosniff
# X-Frame-Options: DENY
# Strict-Transport-Security: max-age=31536000
# Content-Security-Policy: default-src 'self'
# Teste: Verifique mensagens de erro detalhadas
curl -X GET https://api.example.com/users/invalid
# NÃO deve expor stack traces, detalhes do banco de dados ou caminhos internos

API9: Gerenciamento Incorreto de Inventário

Versões antigas da API ainda acessíveis, endpoints não documentados expostos, endpoints de desenvolvimento/staging deixados públicos.

O que testar: Tente acessar /api/v1/ quando /api/v2/ é a versão atual. Verifique caminhos comuns como /debug, /swagger, /graphql, /actuator.

API10: Consumo Inseguro de APIs

A API confia cegamente nos dados de APIs de terceiros sem validação.

Ferramentas de Testes de Segurança de API

OWASP ZAP (Zed Attack Proxy)

Ferramenta de teste de segurança gratuita e de código aberto mantida pela OWASP. Pode escanear APIs automaticamente em busca de vulnerabilidades comuns.

# Execute o ZAP contra sua API usando o scan de API
docker run -t zaproxy/zap-stable zap-api-scan.py \
  -t https://api.example.com/openapi.json \
  -f openapi \
  -r report.html

Burp Suite

A ferramenta padrão do setor para testes de segurança web e de API. O Burp Suite Professional oferece scanning automatizado, intruder (fuzzing) e repeater para testes manuais.

Postman + Scripts de Segurança

Você pode adicionar scripts de teste de segurança às suas coleções Postman existentes:

// Script de teste Postman para verificações de segurança
pm.test("Sem dados sensíveis na resposta", () => {
  const body = pm.response.text();
  pm.expect(body).to.not.include("password");
  pm.expect(body).to.not.include("ssn");
  pm.expect(body).to.not.include("credit_card");
});
pm.test("Cabeçalhos de segurança presentes", () => {
pm.expect(pm.response.headers.get("X-Content-Type-Options")).to.equal("nosniff");
pm.expect(pm.response.headers.get("Strict-Transport-Security")).to.exist;
});
pm.test("Sem divulgação da versão do servidor", () => {
pm.expect(pm.response.headers.get("Server")).to.not.include("Apache/2.4");
pm.expect(pm.response.headers.get("X-Powered-By")).to.not.exist;
});

Qodex.ai

Qodex.ai inclui testes de segurança integrados que escaneiam automaticamente suas APIs em busca de vulnerabilidades do OWASP Top 10. O agente de IA gera casos de teste de segurança junto com testes funcionais, cobrindo desvios de autenticação, ataques de injeção e exposição de dados, sem exigir conhecimento especializado em segurança.

Nuclei

Scanner de vulnerabilidades rápido e baseado em templates. Milhares de templates contribuídos pela comunidade para testes de segurança de API.

# Escaneie uma API em busca de vulnerabilidades conhecidas
nuclei -u https://api.example.com -t api/ -severity critical,high

Comparação de Ferramentas

Checklist de Testes de Segurança de API

Use este checklist para cada API que você criar ou revisar:

Autenticação

• Todos os endpoints exigem autenticação (exceto os públicos)
• Os tokens expiram dentro de um prazo razoável
• A rotação de refresh token está implementada
• As tentativas de login com falha são limitadas por taxa
• Os fluxos de redefinição de senha são seguros
• As chaves de API não são expostas em URLs (use cabeçalhos)

Autorização

• Autorização em nível de objeto em cada endpoint (proteção contra BOLA)
• Autorização em nível de função (endpoints admin restritos)
• Autorização em nível de propriedade (campos sensíveis protegidos)
• A autorização não pode ser contornada alterando o método HTTP

Validação de Entrada

• Toda entrada é validada (tipo, tamanho, formato, intervalo)
• Proteção contra injeção SQL (consultas parametrizadas)
• Proteção contra injeção NoSQL
• Limites de tamanho do corpo da requisição aplicados
• Validação de upload de arquivo (tipo, tamanho, conteúdo)

Proteção de Dados

• HTTPS aplicado (cabeçalho HSTS presente)
• Dados sensíveis não expostos nas respostas (senhas, tokens, PII)
• Dados sensíveis não registrados em logs
• CORS configurado de forma restritiva
• Cabeçalhos de resposta impedem o cache de dados sensíveis

Limite de Taxa e Throttling

• Limites de taxa em todos os endpoints
• Limites mais rígidos nos endpoints de autenticação
• Cabeçalhos de limite de taxa retornados (X-RateLimit-*)
• Código de status 429 retornado quando os limites são excedidos

Integrando Testes de Segurança ao CI/CD

Os testes de segurança devem ser automatizados e executados a cada mudança de código, não apenas antes dos lançamentos.

# GitHub Actions, scan de segurança de API
name: API Security Tests
on:
  push:
    branches: [main, develop]
jobs:
security-scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
  - name: Start API server
    run: docker-compose up -d

  - name: Wait for API
    run: npx wait-on http://localhost:3000/health

  - name: Run OWASP ZAP scan
    uses: zaproxy/action-api-scan@v0.7.0
    with:
      target: http://localhost:3000/openapi.json
      rules_file_name: .zap/rules.tsv
      fail_action: true

  - name: Run custom security tests
    run: npm run test:security

  - name: Upload security report
    if: always()
    uses: actions/upload-artifact@v4
    with:
      name: security-report
      path: zap-report.html

Relacionado: Como Obter uma Chave de API do Rugcheck e Começar a Usar a API

Construindo uma Estratégia de Testes de Segurança Orientada para API

Os testes de segurança de API funcionam melhor quando combinados com outros tipos de testes:

• Testes funcionais, Verificar o comportamento correto (guia de testes de REST API)
• Testes de carga, Verificar desempenho sob pressão (guia de testes de carga de API)
• Testes de integração, Verificar interações entre serviços (guia de testes de integração de API)
• Testes de segurança, Verificar proteção contra ataques (este guia)

Para uma visão abrangente de todas as ferramentas disponíveis, consulte nossa comparação de ferramentas de teste de API.

Perguntas Frequentes

O que são testes de segurança de API?

Os testes de segurança de API são o processo de testar seus endpoints de API em busca de vulnerabilidades, desvios de autenticação, ataques de injeção, exposição de dados e falhas de autorização. O objetivo é identificar e corrigir pontos fracos de segurança antes que os atacantes os explorem.

O que é o OWASP API Security Top 10?

O OWASP API Security Top 10 é uma lista dos riscos de segurança de API mais críticos, mantida pelo Open Worldwide Application Security Project. Inclui Autorização em Nível de Objeto Quebrada (BOLA), Autenticação Quebrada, Autorização em Nível de Propriedade de Objeto Quebrada e outras sete vulnerabilidades comuns de API.

Como inicio os testes de segurança de API?

Comece com o checklist do OWASP API Security Top 10 acima. Execute um scan automatizado com o OWASP ZAP contra sua especificação de API. Em seguida, teste manualmente autenticação, autorização e vulnerabilidades de injeção. Use o Qodex.ai para gerar automaticamente casos de teste de segurança a partir da sua especificação de API.

Quais ferramentas são melhores para testes de segurança de API?

OWASP ZAP (gratuito, scanning automatizado), Burp Suite (testes de penetração profissional), Qodex.ai (geração de testes de segurança powered by IA) e Nuclei (scanning baseado em templates). A maioria das equipes usa uma combinação de ferramentas de testes automatizados e manuais.

Qual é a diferença entre SAST e DAST para APIs?

SAST (Static Application Security Testing) analisa o código-fonte sem executar a aplicação. DAST (Dynamic Application Security Testing) testa a API em execução enviando requisições e analisando respostas. Ambos são valiosos: SAST identifica problemas em nível de código cedo, e DAST encontra vulnerabilidades em tempo de execução.

Com que frequência devo executar testes de segurança de API?

Scans de segurança automatizados devem ser executados a cada implantação (em CI/CD). Testes de penetração abrangentes devem ser realizados trimestralmente ou antes de grandes lançamentos. Monitore continuamente novas vulnerabilidades em dependências usando ferramentas como Dependabot ou Snyk.