Segurança em API Gateway: autenticação, logs, throttling e proteção de APIs
O API Gateway é a porta das suas APIs. Veja como autenticar, limitar e observar sem deixar endpoints abertos.
O API Gateway expõe APIs ao mundo, o que o coloca na linha de frente. Os problemas mais comuns são endpoints sem autenticação adequada, ausência de limites de taxa que permite abuso, e falta de logs que cega tanto a detecção quanto a investigação. Como o Gateway costuma estar na frente de funções Lambda e serviços internos, uma falha aqui expõe tudo o que está atrás.
Este guia trata da segurança do API Gateway de forma defensiva: autenticação por authorizers, controle de taxa, integração com WAF, configuração de CORS e observabilidade. O objetivo é que cada endpoint exposto seja autenticado, limitado e auditável.
Autenticação e authorizers
Cada rota exposta precisa de uma decisão de autenticação explícita. O API Gateway suporta authorizers, como autorização baseada em JWT ou um authorizer Lambda, que validam a requisição antes de chegar ao backend. Evite o padrão perigoso de deixar rotas abertas por descuido, especialmente em APIs que cresceram organicamente e acumularam endpoints esquecidos.
API keys servem para identificar e cotar consumidores, mas não são autenticação por si só, porque uma chave vazada concede acesso. Use API keys junto de autenticação real, não no lugar dela. A autorização precisa acontecer no backend para cada recurso, não apenas no Gateway.
Throttling, WAF e CORS
Configure throttling para limitar a taxa de requisições e proteger o backend contra abuso e picos. Combine com um WAF na frente para mitigar ataques web e padrões maliciosos. A configuração de CORS merece atenção: um CORS permissivo, liberando qualquer origem, pode expor a API a uso indevido a partir de páginas de terceiros.
- Exigir autenticação em toda rota exposta, sem rota aberta por descuido
- Usar authorizers para validar antes do backend
- Tratar API key como identificação, não como autenticação
- Configurar throttling para conter abuso e picos
- Colocar WAF na frente para mitigar ataques web
- Definir CORS restrito, sem liberar qualquer origem
Logs e observabilidade
Habilite logs de acesso e de execução e exporte métricas. Sem logs, abuso de endpoint e tentativas de exploração passam invisíveis, e a investigação fica sem base. Monitore padrões como rajadas de erros de autorização, que indicam tentativas de acesso indevido, e endpoints com volume anômalo. Defina o estágio de produção com configurações mais restritas do que ambientes de desenvolvimento.
Checklist prático
- Exigir autenticação explícita em toda rota exposta
- Usar authorizers (JWT ou Lambda) antes do backend
- Garantir autorização por recurso no backend
- Tratar API keys como identificação, não autenticação
- Configurar throttling por estágio e por consumidor
- Colocar WAF na frente da API
- Definir CORS restrito a origens conhecidas
- Habilitar logs de acesso e de execução
- Monitorar erros de autorização e volume anômalo
- Restringir mais o estágio de produção que o de desenvolvimento
Boas práticas
- Autentique e autorize em camadas, no Gateway e no backend
- Use throttling para proteger o que está atrás do Gateway
- Combine WAF e Gateway para defesa de borda
- Mantenha CORS restrito e revisado
- Observe a API com logs e métricas desde o início
- Elimine endpoints esquecidos e sem dono
Erros comuns
Rota exposta sem autenticação por descuido
Acesso direto ao backend sem qualquer barreira.
Tratar API key como autenticação
Uma chave vazada concede acesso sem segundo controle.
CORS liberando qualquer origem
Páginas de terceiros podem usar a API em nome do usuário.
Sem throttling
Abuso e picos sobrecarregam o backend e elevam custo.
API sem logs
Abuso e exploração passam invisíveis e a investigação trava.
Quando procurar apoio especializado
Revisar autenticação, autorização e exposição de APIs é parte dos serviços de Pentest e de Segurança de Aplicações da GUARDIASEC, que avaliam APIs e endpoints com foco em risco real e evidência.
Perguntas frequentes
API key é suficiente para proteger minha API?
Não. A API key serve para identificar e cotar consumidores, mas não é autenticação robusta: uma chave vazada concede acesso direto. Ela deve ser usada junto de autenticação real, como authorizers baseados em JWT ou Lambda, e a autorização por recurso precisa acontecer no backend. Depender só de API key deixa a API vulnerável.
Onde devo validar a autorização, no Gateway ou no backend?
Em ambos, em camadas. O Gateway valida a autenticação cedo, com authorizers, reduzindo carga indevida no backend. Mas a autorização por recurso, ou seja, se aquele usuário pode acessar aquele objeto, precisa acontecer no backend a cada requisição. Confiar apenas no Gateway costuma deixar brechas de autorização em nível de objeto.
Por que CORS é uma preocupação de segurança?
Um CORS permissivo que libera qualquer origem permite que páginas de terceiros façam requisições à sua API a partir do navegador do usuário, o que pode ser explorado para uso indevido. O recomendado é restringir as origens permitidas às que você controla e ter cuidado redobrado ao permitir credenciais. CORS frouxo é uma exposição comum e subestimada.
Throttling protege contra ataques?
Throttling limita a taxa de requisições, o que mitiga abuso, força bruta e picos que sobrecarregariam o backend. Não é uma defesa completa por si só, mas é uma camada importante, especialmente combinada com WAF e autenticação. Sem throttling, um único consumidor mal-intencionado pode degradar a API e elevar custo rapidamente.
Guias relacionados
Próximo passo
Vamos avaliar os riscos do seu ambiente?
Conte seu cenário e definimos juntos o escopo certo. O objetivo é reduzir caminhos prováveis de ataque e elevar a maturidade de segurança, sem promessas absolutas.