Rate Limiting e Segurança de API: Porque Cada API Pública É uma Responsabilidade Sem Throttling

A vulnerabilidade de API que escala com o sucesso

Um novo produto SaaS lança a sua API. A utilização é baixa; não foi implementado rate limiting porque o volume não o justifica. O produto cresce. A utilização aumenta. A certa altura, a automação de um concorrente começa a raspar a API para inteligência competitiva. Um ator malicioso descobre o endpoint de login e inicia um ataque de credential stuffing, tentativas de login automatizadas usando combinações email/password conhecidas de violações de dados anteriores. Um cliente bem intencionado escreve um script de sincronização que faz loop sem atraso, acedendo à API milhares de vezes por minuto.

Em cada caso, a API responde a cada pedido. Os custos de servidor disparam. O tempo de resposta degrada-se para utilizadores legítimos. Com volume suficiente, o serviço torna-se completamente indisponível.

O rate limiting teria prevenido os três cenários. Não foi implementado porque a equipa de produto estava focada em funcionalidades, não em hardening de infraestrutura.

O OWASP API Security Top 10 lista “Unrestricted Resource Consumption” como um risco de segurança de API de nível superior. O rate limiting é o tipo de infraestrutura que é planeada mas adiada até após um incidente.

A implementação técnica do rate limiting

Rate limiting baseado em IP, rastreia pedidos por endereço IP. Eficaz contra bots e scrapers não sofisticados. Insuficiente para APIs autenticadas onde muitos utilizadores legítimos podem partilhar o mesmo IP.

Rate limiting baseado em chave API, rastreia pedidos por chave API, emitida a clientes autenticados. Permite diferentes rate limits para diferentes tiers (tier gratuito: 100 pedidos/minuto; tier pago: 1000 pedidos/minuto).

Os cabeçalhos de resposta de rate limit que permitem que os clientes gerem o seu próprio volume de pedidos: X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset. A documentação da Mozilla sobre cabeçalhos HTTP documenta estas convenções de cabeçalhos.

A camada de rate limiting da Cloudflare para aplicações web

O Rate Limiting da Cloudflare opera na camada CDN, antes de os pedidos chegarem ao servidor de origem. Isto fornece duas vantagens sobre o rate limiting ao nível da aplicação: protege o servidor de origem do volume de tráfego mesmo quando o limite é excedido, e aplica-se a todos os pedidos incluindo os que visam caminhos não-API (formulários de login, endpoints de checkout, formulários de contacto).

O custo de negócio de rate limits em falta

Os custos de uma API sem rate limiting materializam-se em múltiplas categorias:

Inflação de custos de infraestrutura, um ataque de scraping que gera 50x o volume de pedidos normal produz 50x o custo de computação e largura de banda. A infraestrutura cloud que escala automaticamente para satisfazer a procura escala o custo juntamente com ela.

Fuga de dados, um ataque de scraping bem construído consegue extrair toda a base de dados de produtos de um negócio, estrutura de preços, ou dados de posicionamento competitivo.

Degradação de serviço, com volume de pedidos suficiente, mesmo um ataque de bypass de rate limiting pode degradar o tempo de resposta para utilizadores legítimos. Os padrões de performance do web.dev para tempos de resposta de API tornam-se impossíveis de manter sob tráfego de ataque.

Exposição de credenciais, os ataques de credential stuffing contra endpoints de login usam combinações email/password violadas para testar a reutilização de conta. Sem rate limiting no endpoint de login, uma lista de 10 milhões de credenciais pode ser testada em horas.

O serviço de desenvolvimento de web app do x078 implementa rate limiting como parte de cada especificação de API, não como uma reflexão posterior. O serviço de manutenção inclui auditoria de segurança de API para aplicações web existentes. O serviço de alojamento gerido inclui integração Cloudflare com regras de rate limiting configuradas para padrões de ataque comuns.

Para negócios de SaaS e tecnologia e marcas de e-commerce com APIs públicas, o rate limiting não é uma funcionalidade. É a infraestrutura mínima viável para um serviço de produção. Um endpoint de API sem throttling não é um detalhe técnico, é uma responsabilidade aberta em produção.

O mínimo que cada API precisa

Rate limiting não é uma funcionalidade opcional. É o baseline mínimo de protecção para qualquer API pública. Sem throttling, cada endpoint exposto é uma responsabilidade financeira e de segurança.

A implementação é bem documentada, as ferramentas existem, e o custo de implementar é uma fracção do custo de responder a um incidente causado pela sua ausência.