Como este tema funciona na sua empresa
APIs internas, baixa sensibilidade. Desafio: falta de budget para segurança. Abordagem: autenticação básica (API key), HTTPS obrigatório, sem dados sensíveis em APIs expostas. Validação de entrada simples.
APIs expostas a parceiros/clientes. Desafio: balancear segurança com usabilidade. Abordagem: OAuth2 para autenticação, rate limiting básico, validação de entrada com schema, logging de acessos. Conformidade LGPD começa a importar.
APIs em escala, conformidade regulatória crítica (LGPD, PCI-DSS). Desafio: escalar segurança sem travar agilidade. Abordagem: WAF (Web Application Firewall), mTLS, OWASP compliance contínua, auditoria detalhada, threat modeling.
Segurança de APIs é conjunto de controles de autenticação, autorização, validação de dados e monitoramento implementados para proteger APIs contra abusos, ataques e exposição de dados sensíveis, garantindo que apenas usuários/máquinas autorizados acessem os recursos esperados[1].
Os cinco pilares da segurança de API
Autenticação (quem é você): verificar identidade do cliente. Métodos: API key (simples, frágil), OAuth2 (padrão moderno para delegação), mTLS (mutual TLS, para máquina-a-máquina). Autorização (o que você pode fazer): controlar o que cliente autenticado acessa. Exemplo: cliente A vê dados de A, não de B. Implementar RBAC (roles-based) ou ABAC (attribute-based). Rate limiting (controle de volume): limitar requisições por período (ex: 1000/hora por cliente). Proteção contra abuso e ataques DDoS. Validação de entrada (dados válidos): verificar que dados respeitam contrato (tipo, tamanho, formato). Evitar SQL injection, code injection. Criptografia e logging (sigilo e rastreabilidade): HTTPS obrigatório em trânsito, criptografia em repouso para dados sensíveis, logging de todos os acessos[1].
OWASP API Security Top 10
OWASP (Open Web Application Security Project) publicou "Top 10 de Vulnerabilidades de API". Principais: (1) Broken Object Level Authorization — API não valida que cliente pode acessar recurso (ex: GET /api/users/2 mostra dados de user 2, mesmo que você seja user 1). (2) Broken Authentication — autenticação implementada incorretamente, permitindo credential stuffing ou token roubado. (3) Excessive Data Exposure — API retorna mais dados que necessário, expondo PII. (4) Lack of Resources & Rate Limiting — sem limites, API pode ser abusada (DoS, scraping). (5) Broken Function Level Authorization — usuário comum pode acessar funções de admin. Outros: massa assignment, security misconfiguration, injection, improper assets, logging, CORS misconfiguration[1].
Controles mínimos: (1) API key para cada cliente, (2) HTTPS obrigatório, (3) validação básica de entrada, (4) sem dados sensíveis em respostas. Custo: praticamente zero se já tem HTTPS setup.
Controles moderados: (1) OAuth2 para autenticação, (2) rate limiting por cliente, (3) validação de schema (OpenAPI), (4) logging estruturado com correlation IDs, (5) conformidade LGPD (criptografia, direito ao acesso). Custo: 20-40k USD/ano em ferramentas.
Controles robustos: (1) OAuth2 + mTLS, (2) WAF (Web Application Firewall), (3) rate limiting adaptativo, (4) anomaly detection, (5) SIEM centralizado, (6) penetration testing regular, (7) conformidade OWASP verificada. Custo: 200k-1M USD/ano.
Implementação prática de controles
Autenticação OAuth2: cliente solicita token de acesso, API valida token em cada requisição, token tem TTL (time-to-live) curto. Rate limiting: implementar em gateway ou framework; responder com HTTP 429 quando limite atingido; considerar diferentes limites por plano (free, pro, enterprise). Validação: usar JSON Schema ou OpenAPI; validar tipo, tamanho, formato; rejeitar requisições inválidas com 400 Bad Request. Logging: registrar quem (user ID), o quê (endpoint, método), quando (timestamp), resultado (sucesso/falha); manter por 1+ ano. Criptografia: TLS 1.2+ obrigatório; se dados sensíveis (PII, financeiro) em DB, criptografar; usar key management service (AWS KMS, HashiCorp Vault)
LGPD e regulações em APIs
LGPD exige: rastreabilidade de acesso a dados pessoais, direito ao esquecimento (poder deletar), consentimento documentado. Se sua API expõe dados de cliente, você precisa: (1) autenticação e autorização rigorosa, (2) logging de acessos, (3) criptografia de dados sensíveis, (4) direito de data portability (cliente pode solicitar seus dados em formato estruturado). Exemplo: API de e-commerce que retorna pedidos de cliente deve validar que cliente autenticado vê apenas seus pedidos, não de outros.
Sinais de que sua empresa tem risco de segurança em APIs
Se você se reconhece em três ou mais cenários abaixo, há risco significativo.
- APIs usam API key simples sem versionamento ou rotação
- Não há rate limiting; cliente pode fazer 1M de requisições sem limite
- Ninguém sabe quem acessou qual API e quando (falta de logging)
- API retorna mais dados que necessário (ex: senha em hash, campos internos)
- Autorização é "fraca": user comum consegue acessar dados de outro usuário
- Testes de segurança (pen testing) nunca foram feitos em APIs
- Dados sensíveis transmitidos sem criptografia (em querystring, headers inseguros)
Caminhos para melhorar segurança de APIs
Segurança de API pode ser implementada internamente ou com apoio de segurança especializada.
Viável se você tem engenheiro de segurança ou arquiteto experiente.
- Perfil necessário: Engenheiro de segurança + arquiteto de backend
- Tempo estimado: 4-8 semanas para implementar controles básicos
- Faz sentido quando: APIs internas ou exposição limitada
- Risco principal: conhecimento incompleto de ameaças, missed edge cases
Recomendado para APIs expostas ou com dados sensíveis.
- Tipo de fornecedor: Consultoria de Segurança ou Penetration Testing
- Vantagem: expertise comprovada, threat modeling, testes de segurança
- Faz sentido quando: API em produção com clientes externos ou dados críticos
- Resultado típico: assessment em 2-4 semanas, roadmap de remediation, implementação suportada
Precisa melhorar segurança de APIs?
Se suas APIs expõem dados críticos ou você quer implementar controles de segurança robusto, o oHub conecta você gratuitamente a consultores de segurança especializados. Em menos de 3 minutos, descreva seu contexto.
Encontrar fornecedores de TI no oHub
Sem custo, sem compromisso. Você recebe propostas e decide se e com quem avançar.
Perguntas frequentes
Como proteger APIs corporativas?
Autenticação (OAuth2), autorização (RBAC), validação de entrada (schema), rate limiting, HTTPS obrigatório, logging de acessos, criptografia de dados sensíveis, testes de segurança regulares.
O que é OAuth2 e por que importa em APIs?
Protocolo moderno de autenticação e autorização. Cliente recebe token de acesso com escopo limitado. Melhor que API key porque token tem TTL curto, pode ser revogado, suporta múltiplos níveis de permissão.
Como implementar rate limiting em APIs?
Limitar requisições por cliente/IP por período (ex: 1000/hora). Implementar em gateway, proxy ou framework. Responder com HTTP 429 quando limite atingido. Considerar diferentes limites por plano (free, pro, enterprise).
Como evitar vazamento de dados via APIs?
Validar autorização (cliente vê apenas seus dados), não retornar dados sensíveis (senhas, tokens, IDs internos), criptografar dados sensíveis em trânsito (HTTPS) e repouso (DB encryption), logging de acessos.
Qual é o impacto de OWASP API Security Top 10?
Guia de vulnerabilidades mais críticas em APIs. Implementar controles contra elas reduz 80% do risco. Referência usada para compliance (PCI-DSS, LGPD) e testes de segurança.