API Security

Segurança de API

Checklist de referência para código que expõe APIs. Ao criar, modificar ou revisar endpoints, verifique cada regra aplicável ao trecho em questão antes de considerar o trabalho pronto. Regra violada = corrigir ou documentar explicitamente por que não se aplica ao contexto.

Autenticação

• Use padrões consolidados: JWT ou OAuth 2.0 — Basic Auth só fora de produção, se aceitável
• Prefira bibliotecas e provedores conhecidos a implementações próprias de autenticação, geração de tokens ou hash de senha
• Implemente limite de tentativas e bloqueio temporário contra força bruta
• Criptografe todo dado confidencial em trânsito e em repouso
• Após autenticar com sucesso, emita token para autorizar as requisições seguintes
• Valide o token em cada requisição protegida, antes de processá-la
• Gerencie o ciclo de vida da sessão: TTL de tokens e revogação

JWT

• Gere o segredo de assinatura aleatório, longo e fora do código (cofre de segredos)
• Force o algoritmo no backend (HS256 ou RS256) — trate o campo alg do header como não confiável
• Defina TTL e RTTL tão curtos quanto o caso de uso permitir
• Mantenha o payload livre de dados sensíveis — ele é legível por qualquer um que tenha o token
• Mantenha o payload enxuto — headers HTTP têm limite de tamanho

OAuth

• Valide redirect_uri no servidor contra lista de URLs conhecidas
• Retorne códigos de negociação, nunca tokens de acesso (bloqueie response_type=token)
• Use parâmetro state com valor aleatório para prevenir CSRF no fluxo
• Defina e valide scope por aplicação

Acesso e Transporte

• Implemente rate limiting / throttling contra DDoS e força bruta
• Exija HTTPS em produção, com HSTS habilitado para evitar SSL strip
• Desative listagem de diretórios e SourceMaps em produção
• Para APIs privadas, restrinja acesso a IPs/hosts em whitelist

Requisição

• Use o verbo HTTP correto: GET (obter), POST (criar), PUT/PATCH (atualizar), DELETE (apagar)
• Valide Content-Type da requisição — aceite apenas formatos suportados
• Valide o header Accept — responda 406 Not Acceptable quando não suportado
• Sanitize o conteúdo da requisição contra XSS, SQL Injection e Remote Code Execution
• Dados sensíveis trafegam no header Authorization, nunca na URL
• Toda criptografia acontece no servidor — a criptografia client-side é apenas UX, não controle de segurança
• Use API Gateway para concentrar cache, rate limiting, quota e deploy

Processamento

• Verifique continuamente que endpoints protegidos exigem autenticação — novo endpoint nasce autenticado por padrão
• Prefira rotas que derivam o sujeito do token: /me/orders em vez de /user/654321/orders
• Use UUID em vez de IDs sequenciais para resistir a enumeração
• Ao processar XML, desative entity parsing (XXE) e entity expansion (XML bomb)
• Sirva uploads de arquivos via CDN
• Execute operações pesadas em workers/filas — nunca bloqueando o ciclo HTTP
• Mantenha modo debug desativado em produção (DEBUG=false)
• Use stacks não executáveis quando a plataforma permitir

Resposta

• Envie X-Content-Type-Options: nosniff
• Envie X-Frame-Options: deny
• Envie Content-Security-Policy: default-src 'none'
• Remova headers de identificação: X-Powered-By, Server, X-AspNet-Version
• Envie Content-Type correto na resposta (ex: application/json)
• Respostas nunca carregam senhas, credenciais ou tokens
• Use códigos HTTP corretos: 200, 201, 400, 401, 403, 405, 406, 429, 500

CI/CD

• Cubra a API com testes unitários e de integração
• Exija code review — sem auto-aprovação
• Valide componentes com antivírus/antimalware antes do deploy
• Execute SAST e DAST continuamente
• Verifique dependências contra vulnerabilidades conhecidas
• Implemente rollback de deploy

Armazenamento de Senhas

• Hash com salt usando bcrypt, argon2, scrypt ou PBKDF2
• Salt único por usuário
• Armazene o salt separado do hash