Rate limit só por IP é erro: as camadas que eu protejo no meu SaaS

A pergunta que eu faço pro júnior aqui na empresa

Isso já aconteceu várias e várias vezes na minha empresa, principalmente com a galera júnior. A conversa é sempre a mesma:

Toda API que presta tem tratamento de rate limit. Dispara um monte de requisição pra API da OpenAI agora, pra transcrever áudio que seja, e você vai tomar o limite. Mas eu duvido que muita API de vibe code tenha isso. É básico, é padrão, e pouca gente trata. O meu checklist de quem sobe código feito com IA está em o que eu confiro antes de subir pra produção.

Por que isso vai ficar sério: robô com IA varrendo tudo

Eu já falei de segurança de box pirata. A box pirata vem com worm, com malware, com coisa pré-definida buscando padrão: porta SSH 22 aberta, porta 3000 do Node, que todo mundo que fez cursinho sobe na 3000. Já tem muita invasão assim. Agora imagina a hora que o invasor for uma mini LLM, que se adapta ao ambiente: entrou na box pirata, reconhece que é Android, sabe as portas, reconhece a rede. Mini LLMs focadas em invasão, em ataque, em DDoS.

E saíram as notícias de agentes de IA que se multiplicam. Não é literalmente se reproduzindo, mas escalando de ponta a ponta e acionando outros pontos. Se você já usou o SDK da Anthropic, você entende: ele sozinho cria outros agentes e vai embora, baseado na necessidade. Isso é bem fácil de fazer hoje.

Fui conferir o caso da Wikimedia que eu citei. Em 05/10/2026 a Wikimedia Foundation publicou que achou atividade de agentes "rogue" que ela atribui à OpenAI nos projetos dela: edições sem autorização, tentativas de usar uma ferramenta pública como proxy e milhões de requisições automatizadas às APIs, que podem ter contribuído pra uma queda parcial do Wikidata Query Service em maio. E não é a Wikipédia, é a Wikimedia, a fundação por trás dela. Em 2025 ela já tinha contado que 65% do tráfego mais caro dela vinha de robôs, enquanto os robôs eram só uns 35% das páginas vistas.

É esse o cenário: tráfego monstruoso varrendo tudo quanto é software e site. Quem não trabalhou limite de requisição vai cair.

Rate limit só por IP é um erro catastrófico

Aí vem a segunda pergunta: "você colocou limite baseado em quê?". IP. Aí é que está o erro.

O provedor usa um negócio chamado CGNAT, que basicamente permite que várias pessoas tenham o mesmo IP na internet. A faixa usada dentro da rede do provedor pra isso foi até reservada numa RFC, a RFC 6598 (100.64.0.0/10). Pro seu servidor, um monte de cliente chega com o mesmo IP. Bloqueou um, bloqueou todos.

• CGNAT do provedor. Várias casas atrás do mesmo IPv4 público.
• Órgão público. Usa o mesmo IP pra todo mundo. Se o seu cliente é prefeitura, você derruba a prefeitura inteira.
• Antigamente era pior. Tinha internet a rádio com um IP pra cidade inteira. Hoje melhorou, mas o CGNAT continua no IPv4. No IPv6 isso não entra.

Então o limite tem que ser mais inteligente: IP e dispositivo, e devolvendo 429 quando estoura. O 429 Too Many Requests está na RFC 6585, que ainda recomenda dizer na resposta quanto tempo esperar, pelo cabeçalho Retry-After. Quem vive de bloco de IP sabe o quanto IPv4 é escasso; eu contei a minha fila pelo meu bloco em comprar bloco de IPv4.

E cuidado com a IA que escreve o seu código. Pede "faz um tratamento de rate limit pra mim" sem instruir, e o primeiro que ela coloca é só IP. Por quê? Porque lá no GitHub, onde ela aprendeu com os júnior, a galera só botava IP, e aí dava pau. Até a documentação do módulo de limite do nginx apresenta o limite "em particular" por IP, e responde 503 por padrão. Se você quer 429, tem que pedir.

Rate limit em todas as camadas

O que é o limite de requisição? Uma proteção pra alguma coisa não receber excesso. E ele não é numa camada só. A gente tem rate limit a nível de API e tem rate limit a nível de proxy, pra requisição abusiva morrer antes de chegar na API.

Cloudflare tem limite próprio, e eu já tomei dele: contei em os limites da Cloudflare que ninguém te conta. As regras de rate limit da Cloudflare mostram o mesmo problema na tabela de planos: nos de entrada, a contagem é só por IP; nos maiores aparecem "IP com suporte a NAT", cabeçalho, cookie, ASN. Conferi em 22/10/2026.

Proteja a sua aplicação de você mesmo

"Como assim, me proteger de mim mesmo?" É rate limit dentro da sua própria rede.

A sua aplicação tem limite de requisição no banco de dados? Você fecha as conexões que abre? Ou ela é feita pra, toda hora que chega requisição, abrir conexão, abrir, ir enchendo o pool, enchendo, até travar tudo e dar limite excedido? Isso também é proteção de limite. Você faz na aplicação, obviamente. Mas se usa cluster, coloca também num proxy de banco de dados e represa, protegendo o banco.

E vale pra tudo: get, insert, fila, mensageria. Por quê? Porque a aplicação pode cair em qualquer lugar. Pode dar excesso de requisição em qualquer lugar. Pode dar loop, problema, em qualquer lugar. Escalar máquina não resolve isso, e eu já disse por quê em autoscale não salva aplicação mal feita.

Sem limite, a conta chega

Não é só cair. A nuvem não cobra por requisição? Quando você coloca uma CDN, não cobra por requisição? Pois é. E não estou falando só de arquivo estático: dependendo da abstração com que você trabalha, o Supabase da vida, a Vercel, os caras abstraem tudo, mas te cobram requisição.

Então ou você trabalha as proteções de requisição, ou toma surpresa na conta, ou o sistema cai, ou as duas coisas. Os riscos que me fazem não usar Supabase em produção estão em Supabase em produção: os 3 riscos, e o que eu testo antes de um pico de acesso está em escalar SaaS sem quebrar.

Onde eu ensino isso de verdade

São 20 anos de SaaS, e esse tipo de problema eu já vivi. Hoje eu estou com 19 sistemas autônomos conversando com a minha equipe, só de correção de bug; a maioria das coisas resolve sozinha, com um monte de guardrail pra poder subir. Eu pagaria bem caro pra ter esse norte antes de montar um SaaS.

É isso que eu levo pra Imersão de SaaS, presencial em São Paulo, três dias comigo e com a minha equipe: não é curso de programação, é gestão de SaaS inteira, mas com código, com o pipeline que eu uso pra desenvolver hoje, marketing, suporte, venda, atendimento e jurídico. Nunca foi tão fácil empreender, e nunca foi tão difícil, porque ficou fácil pra todo mundo e a régua disparou. Você consegue o primeiro, o quinto cliente; a hora que o negócio começa a subir, é aí que dá errado se você não tratou o básico.

Perguntas frequentes