Rate limiting: como proteger APIs contra abuso e sobrecarga

APIs sustentam logins, pagamentos, formulários, integrações e recursos dinâmicos de muitos sites e sistemas. Quando recebem mais chamadas do que conseguem processar, a experiência de todos os usuários pode ser afetada.

O rate limiting é uma medida prática para controlar esse consumo. Ele ajuda a manter serviços disponíveis, reduzir abusos automatizados e usar a infraestrutura com mais previsibilidade.

O que é rate limiting e por que ele é essencial para APIs

Rate limiting, ou limitação de requisições, é a definição de um número máximo de chamadas que uma pessoa, aplicação ou origem pode fazer dentro de um período. A regra pode considerar endereço IP, usuário autenticado, token, chave de API, endpoint ou uma combinação desses fatores.

Por exemplo, uma API de login pode aceitar até cinco tentativas por minuto para o mesmo IP. Se esse limite for ultrapassado, novas tentativas ficam temporariamente bloqueadas. Isso dificulta ataques automatizados de tentativa e erro sem impedir o uso normal da página.

Nem todo pico de tráfego é malicioso. Uma campanha, uma integração recém-lançada ou muitos usuários acessando um recurso ao mesmo tempo podem gerar volume legítimo. Ainda assim, sem limites, esse aumento pode consumir CPU, memória, conexões com banco de dados e serviços externos pagos.

Além de complementar boas práticas de segurança para APIs, essa proteção torna o desempenho mais previsível. Uma API estável contribui diretamente para melhorar a performance do site e preservar a experiência de quem está navegando ou usando o sistema.

Quais problemas o rate limiting ajuda a evitar

A limitação de requisições não substitui autenticação, validação de dados, firewall ou monitoramento. Porém, ela reduz a capacidade de um agente abusivo causar dano em pouco tempo e cria uma barreira importante contra vários problemas recorrentes.

• Força bruta: limita tentativas repetidas de login, recuperação de senha ou validação de códigos.
• Scraping excessivo: reduz a coleta automatizada de catálogos, preços, conteúdos e outros dados expostos por endpoints.
• Uso indevido de integrações: impede que uma chave de API ou token consuma recursos muito acima do previsto.
• Sobrecarga de servidor: reduz pressão sobre aplicação, banco de dados, filas e provedores de terceiros.
• Indisponibilidade para usuários reais: reserva capacidade para quem utiliza o serviço de forma legítima.

Imagine um endpoint de consulta de preços acessado por robôs milhares de vezes por minuto. Ao aplicar uma cota por chave de API, clientes autorizados continuam usando a integração dentro de regras claras, enquanto o consumo excessivo é contido.

Em cenários de tráfego hostil, o rate limiting também funciona como uma camada complementar às estratégias de proteção contra DDoS. Ele não resolve sozinho um ataque distribuído de grande escala, mas pode reduzir chamadas repetitivas e evitar que rotas caras sejam exploradas sem controle.

Como definir limites adequados para cada API

Não existe um número universal de requisições por minuto que funcione para todas as APIs. Um endpoint de busca simples pode suportar um volume diferente de uma rota que gera relatórios, envia mensagens ou realiza uma operação financeira.

Comece classificando cada endpoint por criticidade e custo. Avalie quanto ele consome de processamento, banco de dados, serviços externos e tempo de resposta. Rotas de autenticação, recuperação de senha e criação de pedidos normalmente exigem controles mais restritivos.

Também é útil separar os perfis de acesso. Visitantes anônimos podem receber um limite por IP; usuários autenticados, uma cota por conta; e parceiros, um volume contratado por chave de API. Assim, o sistema não trata da mesma forma uma navegação comum e uma integração empresarial legítima.

Uma política possível é permitir 60 chamadas por minuto por IP em uma rota pública de busca e 1.000 chamadas por hora por chave de API em uma integração autenticada. Os valores devem ser ajustados a partir do comportamento real da aplicação, e não escolhidos apenas por conveniência.

Para calibrar essas regras, observe picos, erros, latência e padrão de consumo. Mesmo quando o conteúdo relacionado não aborda diretamente observabilidade, uma arquitetura bem definida entre API REST ou GraphQL ajuda a decidir quais rotas precisam de cotas, autenticação e tratamento diferenciado.

Principais estratégias de rate limiting

Há diferentes algoritmos para controlar requisições. A escolha depende do tipo de tráfego, da tolerância a rajadas e da precisão necessária para aplicar a política.

Fixed Window

O modelo de janela fixa conta as requisições em períodos definidos, como 100 chamadas por minuto. É simples de implementar e entender, mas pode permitir um pico na transição entre duas janelas: um cliente usa toda a cota no fim de um minuto e repete o volume no início do próximo.

Sliding Window

A janela deslizante considera continuamente as chamadas feitas no intervalo anterior. Ela oferece um controle mais equilibrado ao longo do tempo e reduz o efeito de picos concentrados na mudança de janela, embora exija uma implementação um pouco mais cuidadosa.

Token Bucket

No Token Bucket, o cliente recebe tokens que são repostos gradualmente. Cada chamada consome um token. Esse modelo permite pequenas rajadas legítimas, desde que exista saldo disponível, sem liberar tráfego contínuo capaz de saturar o serviço.

Leaky Bucket

O Leaky Bucket processa as requisições em ritmo mais constante, como se o tráfego saísse por um ralo com vazão limitada. É adequado quando a prioridade é suavizar o processamento e evitar que rajadas cheguem aos serviços internos de uma só vez.

Em um sistema de emissão de boletos, por exemplo, o Token Bucket pode acomodar uma sequência curta de ações legítimas sem permitir que uma automação mantenha um volume excessivo por longos períodos. Em ambientes com vários microsserviços, o uso de um API Gateway costuma facilitar a centralização dessas regras.

Onde implementar o rate limiting na arquitetura

O rate limiting pode ser aplicado em mais de uma camada. Em geral, quanto mais cedo o tráfego excessivo for filtrado, menor será a carga que chega à infraestrutura de origem.

• CDN: pode absorver parte do tráfego e aplicar proteções próximas ao usuário.
• WAF e proxy reverso: ajudam a filtrar padrões suspeitos antes de a chamada alcançar a aplicação.
• API Gateway: centraliza autenticação, cotas, regras por consumidor e políticas para múltiplos serviços.
• Aplicação: permite regras ligadas ao contexto de negócio, como limite por conta, recurso ou etapa de um fluxo.

Uma loja virtual pode combinar limites básicos na borda, regras contra bots no firewall de aplicação web e cotas por token no gateway. Essa abordagem em camadas reduz riscos sem concentrar toda a responsabilidade em um único ponto.

O uso de CDN no site pode ajudar a reduzir a pressão sobre a origem, mas não elimina a necessidade de proteger endpoints dinâmicos. APIs de login, checkout, consulta e integrações devem ter regras próprias, pois normalmente exigem processamento no servidor.

Boas práticas para responder quando o limite é atingido

Bloquear uma chamada é apenas parte da solução. A API precisa informar o ocorrido de forma clara para que aplicações clientes, equipes técnicas e usuários saibam como agir.

Quando a cota é excedida, a resposta adequada é o status HTTP 429 Too Many Requests. Sempre que fizer sentido, informe também quando uma nova tentativa poderá ocorrer, por exemplo com o cabeçalho Retry-After.

Clientes bem implementados devem evitar retentativas imediatas. O backoff exponencial, que aumenta gradualmente o intervalo entre tentativas, reduz a chance de amplificar o problema durante um pico ou bloqueio temporário.

Uma resposta prática pode indicar que o limite foi atingido e que uma nova chamada será aceita em 30 segundos. Para integrações de terceiros, uma documentação clara da API deve explicar cotas, critérios de identificação, códigos de erro e comportamento esperado em caso de bloqueio.

Monitoramento e ajustes contínuos das regras

Rate limiting não deve ser configurado uma única vez e esquecido. O comportamento dos usuários, as integrações e a capacidade da infraestrutura mudam com o tempo, por isso as regras precisam ser acompanhadas e revisadas.

Monitore a quantidade de respostas 429, a latência, os erros por endpoint e os identificadores com maior volume, como IPs, tokens e chaves de API. Um aumento repentino pode indicar abuso, falha em um cliente ou uma demanda legítima causada por campanha, lançamento ou crescimento da base.

Antes de aplicar uma nova política em produção, teste-a em ambiente controlado e, quando possível, utilize uma fase de observação. Isso ajuda a identificar limites baixos demais que poderiam bloquear pessoas ou integrações autorizadas.

Após uma campanha de marketing, por exemplo, pode haver um crescimento legítimo de acessos à API. A equipe pode ampliar temporariamente a cota pública, mantendo proteções contra padrões anormais. Esses dados também orientam decisões de capacidade e otimização do servidor.

Proteja a API sem comprometer a experiência legítima

Uma política de rate limiting bem planejada equilibra segurança, desempenho e disponibilidade. Ela reduz abusos, protege recursos críticos e cria regras mais claras para usuários e integrações.

Sua empresa precisa de um site, sistema ou API mais segura e preparada para crescer? Fale com a Codephix para avaliar a infraestrutura, a performance e as proteções ideais para seu projeto em Recife.