A maioria das equipes ativa o Cloudflare WAF como quem instala um antivírus: uma vez configurado, o problema está resolvido. Essa premissa está errada, e o custo de não entendê-la é um falso senso de segurança que pode ser mais perigoso do que nenhuma proteção.
O WAF é uma camada eficaz contra uma classe específica de ameaças. Contra outra classe, ele oferece fricção, não barreira. Saber a diferença determina como você calibra o sistema e o que precisa ser construído no nível da aplicação.
O que os rulesets gerenciados realmente fazem
As regras gerenciadas cobrem as classes de ataque mais comuns: injeção SQL, cross-site scripting, travessia de diretórios, upload de web shells, exploração de CVEs conhecidos em frameworks populares. Elas funcionam por correspondência de assinaturas — o engine inspeciona a requisição e verifica se algum padrão bate com os registrados nas regras.
Esse modelo tem uma limitação intrínseca: opera sobre a forma da requisição, não sobre o significado dela para a aplicação. Uma regra que detecta ' OR 1=1 -- em um parâmetro de query vai disparar tanto para um ataque de SQLi quanto para um usuário legítimo pesquisando tutoriais de SQL. A regra não tem como saber o que aquele parâmetro representa no contexto da sua aplicação — ela só enxerga bytes.
Isso gera falsos positivos previsíveis. Em aplicações com editores de texto rico, endpoints que aceitam HTML como entrada legítima travam em regras de XSS. APIs que recebem JSON com caracteres especiais colidem com regras de SQLi. A proteção é real, mas não é cirúrgica.
O que um atacante paciente consegue fazer
Os rulesets gerenciados são excelentes contra ataques de commodity: scanners automatizados, ferramentas como sqlmap em modo padrão, script kiddies que disparam payloads genéricos. Quem usa esses vetores sem customização vai bater no WAF e parar aí.
O cenário diferente é o atacante que sabe qual WAF está protegendo o alvo — informação frequentemente pública via headers, cookies ou comportamento de resposta. Com esse conhecimento, ele testa sistematicamente técnicas de bypass: codificação incomum (URL encoding em múltiplos níveis, unicode normalization, mixed-case em keywords SQL), payloads fragmentados em corpos grandes, combinações que exploram o limite de processamento do engine.
Contra um atacante determinado que customiza os payloads para o alvo específico, o WAF adiciona trabalho, não impossibilidade. Isso ainda tem valor — aumentar o custo de um ataque reduz o número de atacantes dispostos a pagá-lo. Mas não é uma barreira absoluta, e tratá-la como tal é perigoso.
Há uma categoria de vulnerabilidade onde o WAF simplesmente não entra: lógica de negócio. Se a sua aplicação permite que um usuário visualize os dados de outro por manipulação de IDs na URL (IDOR), o WAF não vai detectar isso. A requisição é formalmente válida, sem payload malicioso. O problema está na lógica da aplicação, e a única proteção eficaz está no código.
Tiers e o que cada plano realmente cobre
A proteção DDoS de camada 3 e 4 está disponível em todos os planos, sempre ativa e sem configuração: mitigação de volumetria na borda, antes de o tráfego chegar à sua infraestrutura.
O WAF de camada 7 — com regras gerenciadas — começa no plano Pro, a USD 20 por mês. Esse tier desbloqueia o Cloudflare Managed Ruleset e o OWASP Core Ruleset. O plano gratuito permite apenas 5 regras customizadas, sem acesso a nenhum ruleset gerenciado. Para a maioria das aplicações com requisitos de segurança reais, o Pro é o piso mínimo aceitável.
As ações disponíveis por regra são: Block (retorna 403 imediatamente), Challenge (exibe um desafio JavaScript que bots não conseguem resolver), Managed Challenge (a Cloudflare decide automaticamente o nível do desafio), Log (registra sem agir), Skip (pula regras específicas ou grupos inteiros) e Allow (passa sem inspeção). A composição dessas ações é onde boa parte da calibração acontece.
Um detalhe que invalida tudo
Existe um pré-requisito que não é óbvio na documentação inicial: o WAF só funciona para registros DNS com o proxy da Cloudflare ativo — o que a interface chama de "orange cloud". Registros configurados como DNS-only (ícone cinza) apontam diretamente para o IP de origem. O tráfego não passa pela Cloudflare, logo nenhuma regra WAF, nenhuma mitigação DDoS de borda, nenhum challenge JavaScript se aplica.
Isso afeta subdomínios deixados como DNS-only por conveniência: ambientes de staging, APIs internas acessadas de fora, serviços auxiliares. Se o atacante descobrir esses subdomínios — e ferramentas de enumeração de DNS tornam isso trivial — ele tem um caminho direto para a origem sem passar pelo WAF. O mapeamento dos seus registros DNS e o estado de cada um precisa ser parte da auditoria de segurança.
O que sua equipe precisa decidir antes de ativar
Ativar os rulesets gerenciados sem um período de observação é receita para bloquear tráfego legítimo em produção. O caminho operacionalmente seguro começa com todas as regras em modo Log: você vê o que seria bloqueado sem bloquear nada, analisa o padrão de disparo e identifica os falsos positivos antes de mudar para Block ou Challenge.
A decisão mais crítica é como tratar as regras que disparam incorretamente. Desabilitar a regra globalmente cria uma brecha para o ataque real que ela protegia. A resposta certa é uma regra Skip com escopo preciso: esta regra gerenciada específica, neste path específico, para esta condição específica. O escopo fechado preserva a cobertura no resto da aplicação.
Também vale decidir antecipadamente o threshold de sensibilidade do OWASP Core Ruleset. Ele funciona por pontuação acumulada — cada regra que dispara adiciona pontos, e a ação acontece quando o total ultrapassa um limite configurável. Um limite muito baixo bloqueia tráfego legítimo; muito alto, deixa passar ataques sofisticados. O ponto de equilíbrio depende da natureza da sua aplicação e do perfil de tráfego que você observou.
O WAF bem configurado é uma defesa sólida contra a maioria dos ataques que você vai receber na prática. O problema é que "bem configurado" exige iteração, não só ativação.
Leia também
- WAF + Rate Limiting + Bot Management: a trifeta de proteção no edge
- Segurança em Aplicativos: Guia de Proteção Mobile
- DNSSEC com Cloudflare: o que protege, o que não protege e como ativar sem problemas
- DNS proxied vs DNS only: o que muda e quando cada modo faz sentido
- Cloudflare Durable Objects: estado consistente no edge — o que realmente muda
- Proteção Contra Vazamento de Dados: Guia de Segurança