Existe uma crença comum de que ativar o Cloudflare Managed Ruleset e o OWASP Core Ruleset é suficiente para ter uma aplicação protegida. A premissa ignora o que esses rulesets foram projetados para fazer — e o que eles deliberadamente não fazem.
Rulesets gerenciados são proteção de largo espectro. Eles foram construídos para funcionar em qualquer aplicação web, de um blog WordPress a uma API de pagamentos, sem nenhum conhecimento sobre o que torna a sua aplicação diferente de qualquer outra. Isso é precisamente o que os limita.
O que os rulesets gerenciados cobrem e onde geram atrito
O Cloudflare Managed Ruleset é atualizado automaticamente quando a Cloudflare detecta novos exploit kits, assinaturas de ataques em larga escala e exploração ativa de CVEs em software popular. Para um time sem equipe de segurança dedicada, isso tem valor real — cobertura contínua sem manutenção manual.
O OWASP Core Ruleset trabalha com classes de ataque catalogadas: injeção SQL, XSS, inclusão de arquivos, deserialização insegura. O modelo de pontuação acumula pontos conforme regras disparam na mesma requisição, e a ação ocorre quando o total cruza um threshold configurável. Esse design reduz falsos positivos de regras isoladas muito sensíveis, mas não os elimina.
Os falsos positivos aparecem de forma previsível em três contextos. Endpoints de API que aceitam JSON com aspas, apóstrofos ou parênteses colidem com regras de SQLi — o engine vê a forma, não o contexto. Painéis administrativos com editores de texto rico disparam regras de XSS quando o usuário salva HTML legítimo num POST. Endpoints de upload binário ativam regras de inspeção de corpo calibradas para texto. Nenhum desses é ataque; todos são comportamentos legítimos da aplicação.
O que as regras customizadas permitem fazer
Regras customizadas operam com conhecimento que os rulesets gerenciados nunca vão ter: o comportamento específico da sua aplicação, o perfil do tráfego legítimo, as ameaças relevantes para o seu caso de uso.
A linguagem de expressão do Cloudflare suporta condições compostas com and, or e not. Um bloqueio por país de origem ip.geoip.country eq "RU" combinado com http.request.uri.path eq "/api/register" restringe apenas o endpoint de cadastro, sem tocar no resto. O campo cf.threat_score gt 10 bloqueia IPs com reputação ruim sem exigir blacklists manuais.
Allowlists para fontes confiáveis são tão importantes quanto as regras de bloqueio. IPs de monitoramento, CI/CD e operadores internos devem ser excluídos de toda inspeção com uma regra de Allow aplicada antes das demais. Sem isso, um check de saúde retorna 403 e um deploy de staging trava em rate limiting — horas de investigação para um problema que não deveria existir.
Rate limiting em endpoints sensíveis pertence às regras customizadas. Logins, recuperação de senha e endpoints de OTP têm perfis de tráfego muito distintos do restante da aplicação. Uma regra limitando /auth/login a 5 requisições por minuto por IP protege contra credential stuffing sem afetar nenhum outro caminho.
O bloqueio de user agents de scrapers maliciosos também cabe aqui: http.user_agent contains "Scrapy" ou http.user_agent eq "" são filtros que um ruleset genérico não vai implementar porque dependem de uma decisão sua sobre quais fontes excluir.
Como resolver falsos positivos sem abrir brechas
Quando um ruleset gerenciado dispara incorretamente, desabilitar a regra globalmente remove a proteção para todos os outros paths onde ela funcionava. A resposta correta é uma regra Skip com escopo preciso: http.request.uri.path eq "/api/content" and cf.waf.rule_id eq "100016" desativa a regra 100016 apenas para aquele path, mantendo a cobertura em toda a aplicação. Escopar por cf.waf.rule_id em vez de por grupo de regras é a diferença entre uma exceção cirúrgica e um buraco.
Os identificadores de regras aparecem nos logs de atividade quando a regra dispara em modo Log — mais um motivo para o período de observação ser obrigatório antes de qualquer bloqueio.
Como calibrar os planos conforme o que está disponível
O plano gratuito oferece 5 regras customizadas e nenhum acesso a rulesets gerenciados. Com 5 regras, a prioridade é clara: allowlist de IPs internos, bloqueio por cf.threat_score alto, rate limiting no endpoint mais crítico. Tentar cobrir tudo com 5 regras resulta em regras amplas demais com efeitos colaterais imprevisíveis.
O plano Pro sobe para 20 regras e desbloqueia os rulesets gerenciados. O plano Business chega a 100 — o que permite criar perfis de proteção distintos por grupo de endpoints: APIs públicas com rate limiting mais permissivo, painéis administrativos com inspeção mais agressiva, webhooks de parceiros com allowlists por IP de origem. Com 20 regras você faz escolhas; com 100 você faz política.
O processo de calibração que funciona na prática
A ordem das operações importa mais do que a configuração específica de cada regra. Começar com o bloqueio ativo em aplicação de produção sem baseline de tráfego é a receita para interromper usuários reais.
A sequência começa com todos os rulesets gerenciados em modo Log por sete a quatorze dias. O painel de atividade do WAF acumula dados reais: quais regras disparariam, com quais frequências, em quais paths. Com esse mapeamento você identifica os candidatos a falso positivo antes que virem incidentes, escreve as regras Skip com escopo correto, e configura as regras customizadas de allowlist e bloqueio.
Só então faz sentido mudar para Managed Challenge ou Block, começando pelas regras de menor risco de falso positivo — CVEs específicos — e avançando para as mais amplas (OWASP SQLi, OWASP XSS) conforme você ganha confiança. A calibração do threshold do OWASP Core Ruleset é a última decisão, porque depende de ver a distribuição real de scores no tráfego da sua aplicação.
WAF calibrado é processo iterativo. O tráfego muda, a aplicação muda, novas features criam padrões de requisição que o ruleset não conhecia. Um endpoint lançado sem as regras Skip correspondentes vai gerar falsos positivos que só aparecem em produção, na hora errada.
Leia também
- O que ainda passa pelo WAF: técnicas de bypass e como mitigar
- 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 WAF: o que a proteção gerenciada realmente bloqueia e o que passa
- WAF em modo log: como ativar proteção gradualmente sem bloquear tráfego legítimo
- WAF + Rate Limiting + Bot Management: a trifeta de proteção no edge