A suposição mais comum de equipes que acabaram de ativar o Cloudflare WAF é que a aplicação agora está protegida. Essa conclusão é tecnicamente incorreta — não porque o WAF não funcione, mas porque os ataques que ele bloqueia são apenas um subconjunto dos que você vai receber. Os outros dois subconjuntos têm produtos diferentes, com lógicas de detecção completamente distintas, e os três raramente são configurados juntos desde o início.
O que cada camada realmente enxerga
A forma mais clara de entender a divisão é pensar em três dimensões do request: o que ele contém, quantos chegam, e quem os está enviando.
O WAF opera sobre o conteúdo — inspeciona o payload do request e verifica se ele corresponde a padrões conhecidos de ataque. Um ' OR 1=1 -- em um parâmetro de query, um script tag em um campo de formulário, uma sequência ../../../etc/passwd em um path: essas são assinaturas que o engine reconhece e bloqueia. O WAF é cirúrgico na dimensão do que, e cego nas outras duas.
Rate Limiting opera sobre a velocidade. Não importa o que o request contém — se um IP está enviando 50 tentativas de login em dez segundos, algo está errado. O WAF não consegue detectar isso porque cada request individual é formalmente válido: a query SQL está correta, não há payload malicioso, a requisição HTTP seria aceita por qualquer servidor sem objeção. O problema não está no formato — está na frequência.
Bot Management opera sobre a identidade comportamental. Um bot sofisticado que randomiza intervalos entre requests, usa um pool de IPs rotativos e mantém taxa dentro dos limites configurados no Rate Limiting vai passar pelas duas primeiras camadas sem fricção. O que entrega esse tipo de tráfego é o fingerprint comportamental: padrões de navegação que não existem em sessões humanas, ausência de eventos de mouse antes de submit, sequências de requests sem os assets auxiliares que um browser real carregaria, uso de TLS fingerprints associados a stacks de automação. Bot Management puntua cada sessão nessa dimensão comportamental e age sobre o score, independente do payload e da velocidade.
Como credential stuffing passa pelo WAF e por quê o Rate Limiting pega
O ataque que melhor ilustra a necessidade das três camadas é credential stuffing com cadência controlada. O atacante tem uma lista de credenciais vazadas de outros serviços e testa cada par contra o endpoint de login da sua aplicação — não em rajadas, mas metodicamente, em 3 a 5 tentativas por minuto por IP. Ele usa proxies residenciais para distribuir as tentativas e garante que nenhum IP individual ultrapasse limites óbvios.
Do ponto de vista do WAF, esse ataque é invisível. O request de login é um POST com campos de email e senha, estruturalmente idêntico ao que qualquer usuário legítimo enviaria. A senha incorreta não é um payload malicioso — é só texto que vai falhar na autenticação. Não há assinatura para o WAF reconhecer.
Com Rate Limiting, você configura uma regra sobre o endpoint /login com uma janela de tempo e um limite de tentativas por IP. Cinco requests em dez segundos dispara Block. Três requests em quinze minutos no endpoint de recuperação de senha, idem. O atacante que calibrou o seu bot para ficar abaixo desse threshold ainda vai passar, mas você eliminou a camada mais barata de credential stuffing — os scripts que simplesmente disparam sem controle de cadência.
O que Rate Limiting não resolve é o atacante que distribui por IPs suficientes para ficar abaixo do limite em cada um. Esse é o espaço onde Bot Management entra: mesmo que cada IP individual faça apenas duas tentativas, o score comportamental da sessão vai indicar automação.
A arquitetura de produto e o que cada plano desbloqueia
Rate Limiting é um produto separado do WAF — não são regras dentro do mesmo sistema, são sistemas com lógicas e configurações independentes. Essa distinção importa na hora de configurar, porque equipes acostumadas a trabalhar só com WAF rules frequentemente procuram Rate Limiting no lugar errado da interface.
As dimensões de controle disponíveis no Rate Limiting incluem IP, combinação de IP com path, cookie específico, e user-agent. As ações são Block, Challenge e Log — com Log sendo o equivalente ao modo de observação do WAF, útil para calibrar limites antes de ativar bloqueio em produção.
O plano gratuito da Cloudflare permite uma única regra de Rate Limiting. O Pro ($20/mês) sobe para cinco regras. O Business para cem. Enterprise remove o limite de regras e desbloqueia o Bot Management completo, incluindo acesso ao cf.bot_management.score como variável em expressões de regra — um número entre 0 e 99 onde valores mais baixos indicam tráfego mais automatizado.
No Pro, o equivalente do Bot Management é o Super Bot Fight Mode: uma configuração simplificada que bloqueia bots definitivamente automatizados, desafia os provavelmente automatizados, e deixa passar o tráfego verificado. Você não acessa o score numérico nem escreve regras baseadas nele, mas a cobertura contra as categorias mais comuns de bot está ativa.
O que a combinação do plano Pro cobre na prática
Com $20 por mês, uma aplicação web com atenção mínima à configuração consegue cobrir a maior parte da superfície de ataque automatizada. O WAF com os rulesets gerenciados da Cloudflare em Block mode para o OWASP level 1 intercepta SQLi, XSS, path traversal e exploração de CVEs conhecidos. As cinco regras de Rate Limiting dão para cobrir os endpoints críticos: login com limite de cinco requests em dez segundos por IP, recuperação de senha com três requests em quinze minutos, registro de conta com dez em uma hora, endpoint de pagamento com dez em uma hora, e raiz da API com cem requests por minuto. Super Bot Fight Mode ativo bloqueia o volume de bots que não tem sofisticação suficiente para disfarçar comportamento.
O que essa combinação não cobre são bots com comportamento genuinamente humano — sessões que navegam em velocidade plausível, com padrões de mouse e teclado sintéticos mas convincentes, usando IPs residenciais com histórico limpo. Esse nível de sofisticação é caro para quem ataca e raro em ataques direcionados a aplicações que não são alvos de alto valor. Para a maioria das aplicações web, a lacuna que fica no Pro é aceitável.
Onde faz sentido escalar para Business ou Enterprise
A decisão de subir de plano é uma equação de risco e custo, não de ambição tecnológica. O Business justifica o salto principalmente se você precisa de mais de cinco regras de Rate Limiting — uma aplicação com dezenas de endpoints sensíveis vai esgotar o limite do Pro rapidamente. Cem regras no Business resolvem esse problema sem chegar no investimento do Enterprise.
O Enterprise faz sentido quando o perfil de ameaça inclui adversários com recursos para contornar detecção simplificada: fraude financeira sofisticada, concorrentes fazendo scraping sistemático de preços com bots que imitam comportamento humano, ou credential stuffing altamente distribuído contra um serviço de alto valor. O acesso ao score numérico do Bot Management permite criar regras com granularidade que o Super Bot Fight Mode não oferece — block acima de 30, challenge entre 30 e 60, allow acima de 60, com lógica adicional por path ou método HTTP. Essa expressividade tem custo, e o custo só é justificado quando o risco mitigado é proporcional.
Uma forma concreta de avaliar: some a receita em risco em caso de fraude bem-sucedida, o custo de uma interrupção por DDoS de camada 7, e o esforço de resposta a incidente para um ataque de credential stuffing em escala. Se esse número é maior que a diferença anual entre o Pro e o Enterprise, a conversa com o fornecedor vale o tempo.
Leia também
- Cloudflare WAF: o que a proteção gerenciada realmente bloqueia e o que passa
- KV para rate limiting, feature flags e configuração distribuída: onde funciona e onde quebra
- DNS proxied vs DNS only: o que muda e quando cada modo faz sentido
- DNSSEC com Cloudflare: o que protege, o que não protege e como ativar sem problemas
- Cloudflare Durable Objects: estado consistente no edge — o que realmente muda
- Email Routing + Workers: processar e-mails programaticamente no edge