Um Web Application Firewall decide, em milissegundos, se um pedido HTTP é tráfego legítimo ou uma tentativa de exploração. Escolher mal essa peça da infraestrutura custa caro: uma regra mal ajustada bloqueia clientes reais, uma regra em falta deixa passar um SQL injection. Este artigo compara os três caminhos mais comuns para equipas portuguesas e europeias em 2026: o WAF gerido da Cloudflare, o AWS WAF nativo da AWS, e o ModSecurity open-source com o Core Rule Set (CRS) da OWASP.
A escolha entre estas três opções não é apenas técnica. Envolve orçamento, quem vai operar o firewall no dia a dia, e que nível de controlo a equipa está disposta a assumir. Vamos comparar preços reais, taxas de deteção, latência, casos de uso concretos e o processo de migração entre eles, com dados de fontes verificáveis como a OWASP, a AWS, a Cloudflare e o projeto Core Rule Set.
O que é um WAF e porque continua a ser essencial em 2026
Um Web Application Firewall inspeciona o tráfego HTTP e HTTPS entre o utilizador e a aplicação, aplicando regras que identificam padrões de ataque conhecidos: injeção de SQL, cross-site scripting, inclusão remota de ficheiros, abuso de APIs, bots maliciosos. Ao contrário de uma firewall de rede tradicional, que filtra por porta e endereço IP, o WAF trabalha à camada 7, lendo o corpo do pedido, os cabeçalhos e os parâmetros da URL.
A lista OWASP Top 10 continua a ser a referência para o que um WAF deve cobrir: injeção, falhas de controlo de acesso, configurações inseguras e falhas criptográficas lideram a lista de riscos que as aplicações web enfrentam. Um WAF bem configurado não substitui código seguro, mas funciona como uma rede de segurança entre o momento em que uma vulnerabilidade é descoberta e o momento em que é corrigida no código-fonte.
Em 2026, o cenário mudou num ponto importante: grande parte do tráfego que os WAFs recebem já não vem de browsers humanos. Vem de agentes de IA a fazer scraping, de bots de scanning automatizado e de ferramentas de teste de penetração assistidas por IA. Isso obriga os três produtos que analisamos aqui a evoluir para lá das regras estáticas, com deteção comportamental e scoring de risco por pedido.
Cloudflare WAF: o que oferece e como funciona
O Cloudflare WAF corre na borda da rede da Cloudflare, antes de qualquer pedido chegar ao servidor de origem. Isto significa que o tráfego malicioso é bloqueado em pontos de presença espalhados pelo mundo, sem consumir capacidade de processamento da própria aplicação. Para uma equipa em Portugal, o ponto de presença mais próximo fica normalmente em Lisboa ou Madrid, o que mantém a latência adicionada muito baixa para utilizadores locais.
O produto inclui managed rulesets (regras geridas pela própria Cloudflare, atualizadas automaticamente conforme surgem novas técnicas de ataque), regras personalizadas escritas em Cloudflare Rules Language, e um painel de Security Analytics que mostra em tempo real que regras estão a disparar e contra que tráfego. A grande vantagem operacional é a simplicidade: ativar o WAF é uma questão de apontar o DNS para a Cloudflare e ligar os rulesets geridos, sem gerir servidores nem escrever regras do zero.
A desvantagem é a dependência de um único fornecedor. Se a Cloudflare tiver uma instabilidade global, o tráfego da aplicação passa por essa instabilidade também, porque todo o tráfego atravessa a rede da Cloudflare antes de chegar à origem. Isto tornou-se um argumento relevante depois de várias interrupções de serviço reportadas por grandes fornecedores de borda ao longo de 2025 e 2026, que levaram equipas de arquitetura a questionar o grau de concentração de tráfego num único ponto.
AWS WAF: integração nativa com a nuvem da Amazon
O AWS WAF segue uma filosofia diferente: em vez de correr numa rede de borda separada, integra-se diretamente com CloudFront, Application Load Balancer, API Gateway e AppSync. Para uma equipa que já tem toda a stack em AWS, isto elimina a necessidade de mudar DNS para um terceiro e mantém o tráfego dentro do perímetro de rede da Amazon do início ao fim.
Segundo a documentação oficial da AWS, o WAF permite escrever regras baseadas em condições IP, geografia, tamanho de pedido, correspondência de strings e regras SQL/XSS geridas, além de suportar rate-based rules que bloqueiam IPs que excedam um número de pedidos num intervalo de tempo. As regras podem ser partilhadas entre múltiplos recursos através de Web ACLs, o que facilita a padronização de políticas em ambientes com dezenas de aplicações.
O ponto fraco mais citado por equipas de engenharia é a curva de configuração. O AWS WAF não tem um “modo automático” comparável ao da Cloudflare: cada regra, cada rate limit e cada exceção tem de ser configurada manualmente ou via infraestrutura como código (Terraform, CloudFormation). Isto dá controlo fino, mas exige tempo de engenharia dedicado, e o modelo de preços por regra e por milhão de pedidos pode escalar de forma pouco previsível em aplicações com picos de tráfego irregulares.
ModSecurity e o Core Rule Set: a via open-source
O ModSecurity é um motor de WAF open-source que corre como módulo de servidores como Apache, Nginx e IIS. Sozinho, o motor não faz nada: precisa de um conjunto de regras, e o mais usado globalmente é o OWASP Core Rule Set (CRS), mantido pela comunidade e financiado em parte pela própria OWASP. O CRS aplica um sistema de scoring por anomalia: cada padrão suspeito num pedido soma pontos, e quando a soma ultrapassa um limiar definido pelo administrador, o pedido é bloqueado.
A grande vantagem é o controlo total e o custo de licenciamento zero. Não há dependência de um fornecedor externo, o código é auditável, e a equipa decide exatamente onde o WAF corre, seja num servidor on-premise, numa VM na cloud ou dentro de um contentor Kubernetes com um ingress controller compatível. Para organizações do setor público português ou empresas com requisitos de soberania de dados que impedem tráfego a passar por redes de terceiros fora da UE, esta é frequentemente a única opção viável.
A desvantagem é que “grátis” não significa “sem custo”. Alguém tem de instalar, afinar os limiares de anomalia, atualizar o CRS quando saem novas versões, e investigar falsos positivos manualmente. Sem uma equipa com experiência em segurança de aplicações, o ModSecurity tende a ficar mal afinado: ou bloqueia tráfego legítimo em excesso, ou fica tão permissivo que perde eficácia contra ataques reais.
Como um WAF inspeciona o tráfego, passo a passo
Vale a pena perceber o que acontece tecnicamente entre o pedido de um utilizador e a resposta da aplicação, porque isso explica muitas das diferenças de desempenho entre os três produtos. Quando um pedido chega, o WAF primeiro faz o parsing do conteúdo: separa cabeçalhos, cookies, parâmetros de query string e corpo do pedido, incluindo payloads JSON ou multipart em uploads de ficheiros. Este passo, por si só, já consome tempo de processamento, e é aqui que a arquitetura de cada produto faz mais diferença.
No Cloudflare e no AWS WAF, esse parsing acontece em infraestrutura dedicada, otimizada especificamente para essa tarefa, e paralelizada em milhares de máquinas distribuídas. No ModSecurity, o parsing acontece dentro do próprio processo do servidor web, o que significa que cada pedido inspecionado compete por CPU com o trabalho normal de servir a aplicação.
Depois do parsing, o motor compara o conteúdo com o conjunto de regras ativo. As regras geridas da Cloudflare e da AWS usam uma combinação de assinaturas conhecidas (padrões de ataque documentados) e modelos de deteção baseados em heurísticas e machine learning, treinados com dados agregados de milhões de sites clientes. O Core Rule Set do ModSecurity é mais determinístico: cada regra tem uma pontuação de anomalia fixa, e o resultado final depende da soma dessas pontuações comparada com o limiar configurado pelo administrador (o “paranoia level”).
Por fim, o WAF toma uma decisão: permitir, bloquear, desafiar com um CAPTCHA, ou apenas registar em log sem intervir. Esta última opção, o modo de deteção, é essencial durante a fase inicial de configuração de qualquer um dos três produtos, precisamente para evitar que regras mal ajustadas bloqueiem tráfego legítimo antes de a equipa ter confiança suficiente para ativar o bloqueio automático.
Tabela comparativa de especificações técnicas
A tabela seguinte resume as diferenças técnicas mais relevantes entre os três produtos, com base na documentação oficial de cada um.
| Característica | Cloudflare WAF | AWS WAF | ModSecurity + CRS |
|---|---|---|---|
| Modelo de implementação | Proxy reverso na borda (edge) | Integrado com CloudFront/ALB/API Gateway | Módulo local no servidor (Apache/Nginx/IIS) |
| Custo de licença | Incluído em planos pagos, camada gratuita limitada | Pago por regra + por milhão de pedidos | Gratuito e open-source (código aberto) |
| Regras geridas automáticas | Sim, atualizadas pela Cloudflare | Sim, AWS Managed Rules (custo adicional) | Sim, via Core Rule Set da comunidade |
| Regras personalizadas | Cloudflare Rules Language | Web ACL rules (JSON/consola) | SecLang (linguagem própria do ModSecurity) |
| Proteção anti-DDoS incluída | Sim, nativa na rede Cloudflare | Parcial, requer AWS Shield à parte | Não, requer solução externa |
| Deteção de bots avançada | Sim (Bot Management, plano superior) | Sim (AWS WAF Bot Control, custo extra) | Limitada, depende de regras adicionais |
| Necessidade de gestão de servidor | Nenhuma (serviço gerido) | Nenhuma para o WAF em si | Sim, requer manutenção do servidor |
| Dependência de fornecedor | Alta (tráfego passa pela rede Cloudflare) | Alta (acoplado ao ecossistema AWS) | Nenhuma (portável entre infraestruturas) |
| Curva de aprendizagem | Baixa a moderada | Moderada a alta | Alta |
| Base de regras open-source | Não (regras proprietárias) | Não (regras proprietárias) | Sim (Core Rule Set, auditável) |
| Suporte a regras GraphQL/JSON | Sim, nativo | Sim, via integração com API Gateway | Sim, desde versões recentes do CRS |
| Melhor cenário de uso | Equipas pequenas/médias que querem proteção rápida | Organizações já totalmente investidas em AWS | Requisitos de soberania de dados ou orçamento zero |
Preços: quanto custa proteger uma aplicação em 2026
O custo de um WAF varia muito consoante o volume de tráfego e o nível de funcionalidades ativado. Abaixo está uma comparação de referência para os planos publicamente disponíveis em 2026 (valores conforme publicado pelos próprios fornecedores).
| Plano | Cloudflare WAF | AWS WAF | ModSecurity + CRS |
|---|---|---|---|
| Entrada | Grátis (proteção básica, sem managed rulesets completos) | Sem plano grátis dedicado, pago desde o primeiro pedido | Grátis (software), custo apenas de infraestrutura |
| Nível intermédio | Plano Pro, com WAF gerido incluído | ~$5/mês por Web ACL + $1/mês por regra + $0,60 por milhão de pedidos | Grátis, custo indireto de uma VM/servidor (~€5 a €40/mês) |
| Nível empresarial | Plano Enterprise, preço sob consulta, inclui bot management avançado | Escala linearmente com nº de regras e pedidos, pode ultrapassar centenas de dólares/mês em tráfego elevado | Grátis, custo cresce com necessidade de servidores redundantes e equipa dedicada |
| Custo de mão de obra | Baixo, configuração simplificada | Médio a alto, requer engenheiro DevOps/Cloud | Alto, requer especialista em segurança de aplicações |
Note-se que o AWS WAF cobra por Web ACL, por regra dentro dessa ACL e por volume de pedidos processados, o que, segundo a documentação oficial da AWS, torna o custo final difícil de prever sem simular o tráfego esperado. Uma aplicação com múltiplas Web ACLs (por exemplo, uma por ambiente: produção, staging, testes) multiplica esse custo base. O ModSecurity, por não ter custo de licença, desloca o gasto para a folha de pagamento: uma hora de trabalho de um engenheiro de segurança sénior custa, em média, mais do que uma subscrição mensal de um plano Cloudflare Pro.
Benchmarks: latência, deteção e taxa de falsos positivos
Comparar benchmarks de WAF é mais difícil do que comparar preços, porque cada fornecedor testa em condições diferentes. Ainda assim, há padrões consistentes reportados por várias fontes ao longo de 2025 e 2026.
- Latência adicionada: o Cloudflare WAF, por correr na borda com pontos de presença próximos do utilizador final, tende a adicionar poucos milissegundos de latência em condições normais, segundo relatórios de desempenho publicados pela própria Cloudflare. O AWS WAF, integrado com CloudFront, apresenta valores semelhantes quando usado junto da CDN, mas pode subir quando ligado diretamente a um Application Load Balancer regional distante do utilizador.
- Falsos positivos com regras geridas out-of-the-box: tanto a Cloudflare quanto a AWS reportam otimização contínua dos seus rulesets geridos para reduzir bloqueios indevidos, mas nenhuma das duas publica uma taxa percentual auditável de falsos positivos em produção real, o que dificulta uma comparação direta e conservadora.
- Ajuste do ModSecurity/CRS: a documentação do Core Rule Set recomenda começar no “paranoia level” 1 (o mais permissivo) e subir gradualmente, precisamente porque níveis mais agressivos (2 a 4) aumentam a deteção mas também disparam mais falsos positivos em aplicações com formulários complexos ou payloads JSON grandes.
- Cobertura do OWASP Top 10: os três produtos afirmam cobrir as categorias principais do OWASP Top 10 (injeção, quebra de controlo de acesso, falhas criptográficas, configuração insegura), mas a profundidade de deteção em cada categoria depende de como as regras são afinadas caso a caso, não apenas de qual produto é escolhido.
- Débito sob carga: o ModSecurity, por correr no mesmo servidor da aplicação, consome CPU e memória da própria máquina que serve o tráfego, o que em picos de carga elevada pode competir por recursos com a aplicação. Os WAFs geridos (Cloudflare e AWS) não têm este problema, porque o processamento acontece em infraestrutura separada da origem.
Uma nota de honestidade editorial: números exatos de percentagem de deteção ou de milissegundos de latência variam tanto por metodologia de teste que qualquer comparação numérica isolada, sem o contexto completo do ambiente testado, deve ser lida com cautela. As tendências acima são consistentes entre a documentação da OWASP, da Cloudflare e da AWS, mas os valores absolutos dependem sempre da configuração específica de cada implementação.
Bypass de WAF: técnicas de evasão que qualquer configuração enfrenta
Nenhum dos três produtos é infalível, e isso é um ponto que qualquer equipa de segurança deve assumir desde o início. Atacantes experientes usam técnicas de ofuscação para contornar regras baseadas em assinaturas: dividir um payload malicioso em vários pedidos, usar codificações alternativas (Unicode, double URL-encoding), ou explorar diferenças na forma como o WAF e a aplicação de destino interpretam o mesmo pedido (um problema conhecido como “parser differential”).
O Core Rule Set documenta abertamente este tipo de limitação, precisamente porque é um projeto open-source cujas regras podem ser estudadas por qualquer atacante com acesso ao repositório público no GitHub. Isto não torna o ModSecurity menos seguro por definição, mas exige que a equipa combine o WAF com outras camadas de defesa, como validação de input no próprio código da aplicação e monitorização de comportamento anómalo pós-bloqueio.
Nos produtos geridos, a Cloudflare e a AWS não publicam os detalhes internos dos seus algoritmos de deteção, o que dificulta a um atacante estudar as regras antecipadamente, mas também dificulta à própria equipa cliente perceber exatamente porque um pedido específico foi bloqueado ou permitido. Este é o principal argumento a favor da transparência do modelo open-source: numa auditoria de segurança, é mais fácil demonstrar conformidade quando é possível mostrar o código exato das regras aplicadas, algo que nem o Cloudflare WAF nem o AWS WAF permitem da mesma forma.
Casos de uso reais: quem usa o quê e porquê
Cinco cenários concretos ajudam a decidir qual WAF faz mais sentido consoante o contexto da organização.
1. Startup SaaS em fase de crescimento. Uma equipa pequena, sem engenheiro de segurança dedicado, que precisa de proteção “pronta a usar” rapidamente. O Cloudflare WAF é normalmente a escolha certa: ativa-se em minutos, os managed rulesets cobrem o essencial do OWASP Top 10, e o painel de analytics dá visibilidade sem exigir conhecimento profundo de regras SecLang.
2. Empresa com toda a infraestrutura em AWS. Uma organização que já usa API Gateway, Lambda e CloudFront para tudo beneficia de manter o WAF dentro do mesmo ecossistema, com Web ACLs geridas via Terraform junto do resto da infraestrutura como código. Evita-se mudar DNS para um terceiro e mantém-se um único painel de faturação e de logs (CloudWatch).
3. Setor público ou banca com requisitos de soberania de dados. Organizações sujeitas a regras rigorosas de onde os dados podem transitar, incluindo entidades públicas portuguesas e instituições financeiras reguladas, frequentemente não podem, ou não querem, encaminhar todo o tráfego de utilizadores por uma rede de borda de um fornecedor terceiro fora do seu controlo direto. Nestes casos, o ModSecurity instalado em infraestrutura própria, ou numa cloud privada auditável, é a via preferida, apesar do esforço de manutenção adicional.
4. Aplicação com tráfego internacional elevado e necessidade de baixa latência. Um serviço de e-commerce ou media com utilizadores em múltiplos continentes beneficia da rede de pontos de presença globais da Cloudflare, que reduz a distância física até ao ponto de inspeção do WAF, algo que uma instalação ModSecurity centralizada num único datacenter não consegue replicar sem investimento significativo em infraestrutura distribuída.
5. Equipa de segurança com necessidade de regras muito específicas e auditáveis. Bancos de investimento, fintechs sujeitas a auditoria externa rigorosa ou empresas de defesa que precisam de justificar exatamente porque cada pedido foi bloqueado ou permitido, e que preferem código de regras que podem ler linha a linha, tendem a preferir o Core Rule Set: é possível auditar cada regra, ao contrário das regras proprietárias fechadas da Cloudflare ou da AWS.
Conformidade: NIS2, RGPD e a escolha do WAF na Europa
Para equipas em Portugal e no resto da União Europeia, a escolha de um WAF já não é apenas uma decisão de engenharia. A Diretiva NIS2, transposta para o direito português, alarga o número de setores obrigados a implementar medidas técnicas de gestão de risco em segurança de redes e sistemas de informação, o que inclui explicitamente proteção contra ataques a aplicações web em serviços considerados essenciais ou importantes.
Isto cria uma tensão prática entre conveniência e conformidade. Um WAF gerido por um fornecedor fora da União Europeia simplifica a operação, mas obriga a equipa a documentar, para efeitos de auditoria, exatamente que dados transitam por esse fornecedor, onde são processados, e sob que base legal ao abrigo do RGPD. Um WAF auto-alojado, como o ModSecurity, evita essa complexidade de transferência internacional de dados, mas transfere a responsabilidade de manter o sistema atualizado e eficaz inteiramente para a equipa interna, algo que a própria NIS2 também audita.
Na prática, muitas organizações europeias resolvem este dilema optando por planos empresariais da Cloudflare ou da AWS com regiões de processamento de dados dentro da UE, mantendo assim os benefícios operacionais de um serviço gerido sem comprometer os requisitos de residência de dados. Outras, sobretudo no setor público, preferem manter o controlo total através de soluções open-source, aceitando o custo adicional de engenharia como parte do preço da soberania digital.
Guia de migração entre WAFs
Migrar de um WAF para outro é um processo que exige planeamento cuidadoso, porque um erro de configuração pode deixar a aplicação exposta durante a transição ou bloquear tráfego legítimo sem aviso. Segue-se um guia genérico aplicável às três direções de migração mais comuns.
Passo 1: Auditar as regras atuais
Antes de mudar de fornecedor, documente todas as regras ativas no WAF atual: que categorias do OWASP Top 10 cobrem, que exceções (allowlists) foram criadas ao longo do tempo, e porquê. Muitas exceções existem por razões históricas esquecidas, e recriá-las sem entender o motivo original é uma fonte comum de incidentes pós-migração.
Passo 2: Configurar o novo WAF em modo de deteção (não bloqueio)
Tanto o Cloudflare quanto o AWS WAF suportam um modo “log only” (registar sem bloquear), e o ModSecurity suporta um modo de deteção equivalente via a diretiva SecRuleEngine DetectionOnly. Corra o novo WAF em paralelo com o antigo, apenas a registar decisões, durante pelo menos uma a duas semanas de tráfego real, incluindo períodos de pico.
Passo 3: Comparar os logs dos dois sistemas
Identifique pedidos que o WAF antigo bloqueava mas o novo deixaria passar (lacunas de cobertura) e pedidos que o novo bloquearia mas o antigo deixava passar (potenciais falsos positivos novos). Ajuste os thresholds do novo sistema antes de avançar para produção.
Passo 4: Migrar por fases, não de uma vez
Se possível, migre um subdomínio ou uma rota da API de cada vez, em vez de trocar todo o tráfego de uma só vez. Isto limita o impacto de um erro de configuração a uma pequena fatia dos utilizadores, em vez de afetar toda a base de clientes simultaneamente.
Passo 5: Manter o sistema antigo em standby durante 30 dias
Só desative por completo o WAF anterior depois de confirmar, com dados reais de produção, que o novo sistema mantém pelo menos o mesmo nível de proteção. Isto é especialmente relevante ao sair do ModSecurity para um serviço gerido, porque perde-se a capacidade de inspecionar o código das regras que estavam a funcionar.
Prós e contras de cada opção
Cloudflare WAF
- Prós: configuração rápida, rede de borda global reduz latência, inclui proteção anti-DDoS nativa, painel de analytics acessível, atualização automática de regras contra ameaças emergentes.
- Contras: dependência total da disponibilidade da rede Cloudflare, regras proprietárias não auditáveis, custo cresce em planos Enterprise para funcionalidades avançadas de bot management.
AWS WAF
- Prós: integração nativa com todo o ecossistema AWS, controlo fino via infraestrutura como código, Web ACLs partilháveis entre recursos, boa opção para quem já paga pela AWS.
- Contras: preço difícil de prever a longo prazo, curva de configuração mais alta, sem “modo automático” simples, exige conhecimento de Terraform/CloudFormation para escalar bem.
ModSecurity + Core Rule Set
- Prós: gratuito, código auditável, portável entre qualquer infraestrutura, sem dependência de fornecedor externo, ideal para requisitos de soberania de dados.
- Contras: exige especialista dedicado para afinação, sem proteção anti-DDoS nativa, consome recursos do próprio servidor, manutenção contínua do Core Rule Set fica a cargo da equipa interna.
Veredito: qual WAF escolher em 2026
Não existe um vencedor universal, porque cada um dos três produtos resolve um problema ligeiramente diferente. Com base nos dados comparados acima, a recomendação prática divide-se assim:
Para a maioria das equipas pequenas e médias sem departamento de segurança dedicado, o Cloudflare WAF continua a ser o ponto de partida com melhor relação entre esforço de configuração e nível de proteção obtido, sobretudo pela combinação de WAF, CDN e proteção anti-DDoS num único serviço gerido. Para organizações já profundamente investidas na AWS, com equipa DevOps capaz de gerir infraestrutura como código, o AWS WAF evita a complexidade de introduzir um quarto fornecedor na cadeia e mantém tudo dentro do mesmo painel de faturação e de observabilidade. Para quem tem requisitos legais de soberania de dados, orçamento zero para licenças, ou precisa de auditar cada regra linha a linha, o ModSecurity com o Core Rule Set continua a ser a única via viável, com o custo trocado de licença para tempo de engenharia especializada.
Na prática, muitas organizações maduras não escolhem apenas uma: usam o Cloudflare ou o AWS WAF como primeira linha de defesa na borda, e mantêm regras ModSecurity adicionais mais específicas junto da aplicação, como camada extra para tráfego que já passou pela borda. Esta abordagem em profundidade reduz o risco de um único ponto de falha na estratégia de proteção contra ataques web.
Erros comuns na configuração de um WAF
Independentemente do produto escolhido, certos erros de configuração repetem-se em auditorias de segurança de aplicações web. O primeiro é ativar o WAF em modo bloqueio total sem passar primeiro por um período de deteção, o que costuma gerar uma onda de reclamações de utilizadores legítimos bloqueados por engano. O segundo é confiar apenas nas regras geridas por defeito sem as adaptar ao contexto específico da aplicação: um formulário que aceita blocos grandes de texto, como um editor de artigos, precisa de exceções que uma aplicação de checkout simples não precisa.
O terceiro erro comum é esquecer de proteger as APIs internas e endpoints administrativos com o mesmo rigor da aplicação principal, deixando uma rota de gestão sem WAF ativo como ponto de entrada alternativo. O quarto é nunca rever os logs do WAF depois da configuração inicial: um WAF que bloqueia ataques silenciosamente, sem ninguém a analisar os padrões de tentativas, perde uma fonte valiosa de informação sobre que tipo de ameaças a aplicação enfrenta ao longo do tempo. O quinto erro, mais subtil, é tratar o WAF como uma solução definitiva em vez de uma camada entre várias: código com validação de input fraca continua vulnerável, mesmo atrás do melhor WAF do mercado, assim que um atacante encontra uma forma de contornar as regras ativas.
Observabilidade: o que fazer com os dados do WAF
Um WAF gera um volume considerável de dados: cada pedido bloqueado, desafiado ou permitido fica registado, com o motivo da decisão. A diferença entre uma equipa madura e uma equipa reativa está em como esses dados são usados depois. Os três produtos exportam logs em formatos estruturados (JSON), compatíveis com ferramentas de análise como o Wazuh, o Microsoft Sentinel ou soluções equivalentes de SIEM, o que permite correlacionar eventos de WAF com outros sinais de segurança, como tentativas de login falhadas ou alterações de permissões.
Uma prática recomendada é definir alertas para padrões específicos, não apenas para o volume total de bloqueios: um pico súbito de tentativas de SQL injection vindas de um único intervalo de IPs, por exemplo, é normalmente mais relevante do que um aumento genérico no número de pedidos bloqueados, que pode simplesmente refletir mais tráfego de bots comuns. A resposta a incidentes beneficia diretamente da qualidade destes dados: quando um ataque é bem-sucedido apesar do WAF, os logs de pedidos bloqueados nas horas anteriores frequentemente mostram o reconhecimento inicial que precedeu a exploração, uma pista valiosa para entender como o atacante escolheu o seu alvo.
WAF e APIs: um desafio à parte
A proteção de APIs REST e GraphQL levanta desafios que um WAF tradicional, pensado para formulários HTML, nem sempre resolve bem. Payloads JSON aninhados, autenticação via tokens Bearer, e queries GraphQL que combinam múltiplos campos num único pedido POST exigem regras específicas, não apenas os padrões clássicos de deteção de SQL injection em parâmetros de URL.
Os três produtos analisados oferecem funcionalidades dedicadas a este cenário: a Cloudflare tem regras específicas para GraphQL que limitam profundidade de queries e complexidade, o AWS WAF integra-se diretamente com o API Gateway para inspecionar pedidos antes de chegarem às funções Lambda, e o Core Rule Set do ModSecurity inclui, desde versões recentes, regras adaptadas a corpos JSON. Ainda assim, equipas que gerem APIs críticas devem tratar a configuração do WAF para APIs como um projeto à parte da configuração para o tráfego web tradicional, com testes de regressão próprios.
Perguntas frequentes
Um WAF substitui a necessidade de corrigir vulnerabilidades no código?
Não. Um WAF é uma camada de mitigação, não uma correção. Reduz o risco de exploração enquanto a vulnerabilidade não é corrigida no código-fonte, mas não elimina a causa raiz do problema.
É possível usar mais do que um WAF ao mesmo tempo?
Sim, e é uma prática comum em ambientes com requisitos de segurança elevados: um WAF na borda (Cloudflare ou AWS) como primeira linha, e regras adicionais mais específicas junto da aplicação para uma segunda camada de verificação.
O plano gratuito da Cloudflare já inclui proteção suficiente?
O plano gratuito oferece proteção básica, mas não inclui o conjunto completo de managed rulesets nem as funcionalidades avançadas de bot management. Para aplicações que processam dados sensíveis ou pagamentos, um plano pago com regras geridas completas é recomendado.
Quanto tempo demora a afinar corretamente um ModSecurity com o Core Rule Set?
Depende da complexidade da aplicação, mas raramente é um processo de dias. Equipas com experiência em segurança de aplicações contam normalmente semanas de ajuste iterativo até atingir um equilíbrio estável entre deteção e falsos positivos, especialmente em aplicações com formulários complexos.
O AWS WAF protege automaticamente contra ataques DDoS?
Não de forma completa. O AWS WAF foca-se em ataques à camada de aplicação. Para proteção anti-DDoS mais ampla, a AWS recomenda combinar com o AWS Shield, um serviço separado com o seu próprio modelo de preços.
Empresas portuguesas do setor público podem usar WAFs geridos por fornecedores fora da UE?
Depende do enquadramento regulatório específico da entidade e dos dados processados. Muitas entidades públicas e reguladas optam por soluções auditáveis e alojadas em infraestrutura sob jurisdição europeia, precisamente para evitar questões de transferência de dados para fora da UE, o que favorece opções como o ModSecurity em infraestrutura própria ou clouds com regiões dedicadas na Europa.
Um Core Rule Set desatualizado é um risco de segurança?
Sim. Novas técnicas de evasão de WAF surgem regularmente, e o Core Rule Set é atualizado pela comunidade para as cobrir. Manter a versão do CRS desatualizada é equivalente a não aplicar patches de segurança: a proteção vai ficando cada vez menos eficaz contra as ameaças mais recentes.
Cobertura relacionada
- pfSense vs OPNsense: 5.675 vs 4.492 Stars, Qual Firewall Escolher [2026]
- Burp Suite vs OWASP ZAP: $449/ano vs Grátis [2026]
- REST API vs GraphQL: Segurança 250ms vs 62% Menos Dados [2026]
- Wazuh vs Microsoft Sentinel: $0 vs $4,30/GB [2026]
- Pentest de APIs Node.js: 12 Passos para Testar a Segurança [2026]
Para mais cobertura sobre proteção de aplicações, vulnerabilidades e resposta a incidentes, consulte a secção de Cibersegurança do shattered.io.
