WAF é a sigla para Web Application Firewall — um firewall que analisa o conteúdo das requisições HTTP que chegam ao seu site, e não apenas de onde elas vêm. É essa a diferença para um firewall comum: enquanto o firewall de rede decide com base em IP e porta, o WAF lê o que está sendo enviado e bloqueia padrões de ataque como SQL injection, cross-site scripting e tentativas de exploração de falhas em plugins.
Mas há uma distinção que a maioria dos artigos ignora e que decide o quanto você está de fato protegido: onde o WAF roda. Um WAF em plugin, um no servidor e um na nuvem entregam níveis de proteção muito diferentes — e o primeiro, que é o mais comum em sites WordPress, é também o que menos protege contra os ataques mais pesados.
WAF = firewall que entende HTTP. Analisa o conteúdo da requisição, não só o endereço de origem.
| Firewall comum | Bloqueia por IP e porta. Não vê o conteúdo |
| WAF | Lê a requisição inteira e bloqueia padrões de ataque |
| Os dois juntos | É a configuração correta. Não são alternativas |
Conteúdo
Firewall comum e WAF: a diferença na prática
Um firewall de rede trabalha em uma camada mais baixa. Ele vê pacotes: de onde vieram, para qual porta vão, qual protocolo usam. Com base nisso decide se passa ou não. É extremamente eficaz para bloquear acesso indevido a serviços — SSH, banco de dados, painel de controle. Nosso guia sobre o que é firewall cobre esse funcionamento.
O problema é que um ataque a um site usa a porta certa. Uma tentativa de SQL injection chega pela porta 443, com HTTPS válido, vinda de um IP que nunca fez nada suspeito. Para o firewall de rede, é uma requisição legítima — e é, tecnicamente. O que a torna um ataque é o conteúdo.
É aí que entra o WAF. Ele lê a requisição completa — URL, parâmetros, cabeçalhos, corpo, cookies — e compara com padrões conhecidos de ataque.
| Firewall de rede | WAF | |
|---|---|---|
| Decide com base em | IP, porta, protocolo | Conteúdo da requisição HTTP |
| Protege contra | Acesso indevido a serviços e portas | Ataques à aplicação — injeção, XSS, exploração de falhas |
| Não protege contra | Ataques que usam portas legítimas | Acesso direto a serviços fora do HTTP |
| Analogia | O porteiro que confere quem entra | O segurança que revista o que a pessoa carrega |
Os dois são complementares, não alternativos. Um servidor bem protegido tem os dois: o firewall de rede fechando o que não precisa estar aberto, e o WAF inspecionando o que passa pelo que precisa.
Contra o que um WAF protege
Os ataques que ele bloqueia são, na prática, os mais comuns contra sites:
SQL injection — o atacante insere comandos de banco de dados em campos de formulário ou parâmetros de URL, tentando ler, alterar ou apagar dados. Um formulário de busca mal programado pode expor a base inteira.
Cross-site scripting (XSS) — injeção de JavaScript malicioso em páginas do seu site, que executa no navegador dos visitantes. Serve para roubar sessões, redirecionar usuários ou exibir conteúdo falso.
Exploração de vulnerabilidades conhecidas — a mais frequente em WordPress. Quando surge uma falha em um plugin popular, bots começam a varrer a internet em busca de sites que ainda não atualizaram. Um WAF com regras atualizadas bloqueia essas tentativas mesmo antes de você atualizar — é o que se chama de virtual patching, e é provavelmente o benefício mais concreto de ter um.
Inclusão de arquivos e path traversal — tentativas de acessar arquivos fora do diretório do site, como o wp-config.php ou arquivos de sistema.
Força bruta em formulários de login — tentativas repetidas de adivinhar senhas, que o WAF detecta pelo padrão de repetição.
Bots maliciosos e scrapers — tráfego automatizado que consome recursos sem trazer visitantes. Vale lembrar que boa parte do tráfego da internet não é humana, e nem todo bot é bem-intencionado.
Onde o WAF roda — e por que isso muda tudo
Esta é a parte que a maioria dos artigos não explica, e é o que separa proteção real de sensação de proteção.
| Tipo | Onde analisa | Exemplos |
|---|---|---|
| De nuvem | Antes de o tráfego chegar ao seu servidor | Cloudflare, Sucuri |
| De servidor | No servidor, antes de o PHP rodar | ModSecurity, cPGuard, Imunify360 |
| De aplicação (plugin) | Dentro do WordPress, depois de o PHP carregar | Wordfence, Sucuri (plugin) |
A diferença prática é grande:
Um WAF de plugin roda em PHP, dentro do WordPress. Isso significa que a requisição maliciosa já chegou ao seu servidor, já consumiu conexão, memória e processamento — e só então foi barrada. Ele impede a execução do ataque, mas não impede o consumo de recursos. É por isso que um site com plugin de segurança ainda fica lento sob um ataque de volume.
Um WAF de servidor roda antes do PHP. O ModSecurity, por exemplo, é um módulo do servidor web: ele inspeciona a requisição e a descarta antes que o WordPress sequer seja carregado. Muito mais leve.
Um WAF de nuvem nem deixa o tráfego chegar. Como o DNS aponta para a rede do provedor, o filtro acontece lá — e o seu servidor nunca vê a requisição. É o único tipo que protege de verdade contra ataques de volume, porque a carga é absorvida fora.
É a confusão mais comum sobre o tema. Um plugin como o Wordfence tem um WAF competente e faz muito bem o trabalho de bloquear ataques à aplicação — mas ele roda dentro do WordPress. Num ataque de volume, cada requisição ainda carrega o PHP antes de ser barrada, e o servidor cai por esgotamento de recursos mesmo com o plugin funcionando perfeitamente. Proteção contra DDoS exige filtro antes do servidor: nuvem ou infraestrutura da hospedagem.
Regras: como um WAF decide o que bloquear
Um WAF funciona com conjuntos de regras — padrões que identificam requisições maliciosas. O mais conhecido é o OWASP Core Rule Set, um conjunto aberto e mantido pela comunidade que cobre as categorias de ataque mais frequentes, e que serve de base para praticamente todo WAF sério.
Além dele, provedores mantêm regras próprias, atualizadas quando surge uma vulnerabilidade nova. É essa atualização que dá ao WAF o valor do virtual patching: quando uma falha crítica é descoberta num plugin popular, a regra que a bloqueia costuma chegar antes de o desenvolvedor lançar a correção — e muito antes de o dono do site aplicá-la.
E existe o outro lado. Regras muito agressivas produzem falsos positivos: requisições legítimas bloqueadas por parecerem ataque. O caso clássico é o administrador que tenta salvar um post contendo trechos de código, ou tags HTML, e recebe um erro 403. O WAF leu o conteúdo como tentativa de injeção.
Quando isso acontece, a solução é ajustar ou liberar a regra específica, não desativar o WAF — nosso guia sobre o erro 403 Forbidden trata desse cenário.
WAF na hospedagem compartilhada
Uma pergunta prática: se você está em hospedagem compartilhada, provavelmente já tem um WAF rodando e não sabe.
A maioria das hospedagens sérias mantém ModSecurity ou uma solução equivalente no servidor, com regras aplicadas a todas as contas. Isso protege você mesmo sem nenhuma configuração da sua parte — e é também a explicação para alguns bloqueios que parecem inexplicáveis, como o formulário que para de enviar depois de você acrescentar um campo com código.
O que você pode fazer:
- Perguntar ao suporte se há WAF ativo e qual
- Pedir ajuste de regra quando um falso positivo bloquear algo legítimo. Isso é rotina para o suporte
- Não instalar um plugin de WAF esperando dobrar a proteção. Ele roda numa camada diferente, então não é redundante — mas também não substitui o do servidor, e consome recursos da sua conta
Na Homehost, os planos incluem o cPGuard, que faz esse papel no servidor: antivírus, firewall de aplicação, limpeza automática de injeções em arquivos e detecção de CMS e plugins desatualizados.
Preciso de um WAF de nuvem também?
Depende do risco que você corre, e vale ser honesto sobre isso:
Provavelmente não, se o seu site é institucional ou um blog, com tráfego moderado, e a hospedagem já tem WAF de servidor. A proteção existente cobre o cenário realista.
Provavelmente sim, se você tem loja virtual com volume relevante, já sofreu ataque de negação de serviço, opera em setor visado (financeiro, jogos, política), ou tem obrigação contratual de proteção.
O ponto de decisão costuma ser o DDoS: se ataques de volume são uma preocupação real, o filtro precisa estar antes do seu servidor, e nenhuma solução instalada nele resolve isso. Nosso guia sobre o que é CDN e Cloudflare cobre como funciona essa camada.
O que um WAF não faz
Vale delimitar, porque WAF é frequentemente vendido como solução completa de segurança e não é:
- Não corrige a vulnerabilidade. Ele bloqueia a tentativa de exploração, mas a falha continua no código. Atualizar plugins, temas e o próprio WordPress continua sendo obrigatório
- Não protege contra senha fraca. Se o atacante acerta a senha, a requisição é legítima
- Não remove malware já instalado. Isso é trabalho de scanner e limpeza
- Não substitui backup. Nenhuma proteção é perfeita, e restaurar continua sendo o plano de contingência
- Não protege serviços fora do HTTP. SSH, FTP e banco de dados são responsabilidade do firewall de rede
Os planos da Homehost incluem o cPGuard, com firewall de aplicação, antivírus, limpeza automática de injeções em arquivos e detecção de CMS desatualizado — rodando no servidor, antes do PHP, sem consumir recursos do seu site. Servidor no Brasil, CloudLinux isolando cada conta e suporte em português que ajusta regras quando preciso.
Ver planos de hospedagemPerguntas frequentes
O que é WAF?
WAF é a sigla de Web Application Firewall — um firewall que analisa o conteúdo das requisições HTTP que chegam ao site, e não apenas a origem delas. Ele lê URL, parâmetros, cabeçalhos e corpo da requisição, comparando com padrões conhecidos de ataque para bloquear tentativas de SQL injection, cross-site scripting e exploração de vulnerabilidades.
Qual a diferença entre firewall e WAF?
O firewall de rede decide com base em endereço IP, porta e protocolo — ele vê de onde a requisição vem, não o que ela contém. O WAF analisa o conteúdo da requisição HTTP. Como um ataque a um site usa a porta legítima do HTTPS, o firewall de rede não o distingue de tráfego normal; é o WAF que identifica o padrão malicioso. Os dois são complementares.
Um plugin de segurança do WordPress é um WAF?
Plugins como o Wordfence incluem um WAF, sim, e ele funciona bem contra ataques à aplicação. A diferença é onde roda: como é um plugin, ele executa dentro do WordPress, depois que o PHP já carregou. A requisição maliciosa chega ao servidor e consome recursos antes de ser barrada. Um WAF de servidor ou de nuvem filtra antes disso.
WAF protege contra ataque DDoS?
Só se for um WAF de nuvem. Um plugin ou um WAF instalado no servidor bloqueia as requisições, mas elas já chegaram — e num ataque de volume, o servidor cai por esgotamento de recursos mesmo com a proteção funcionando. Filtrar DDoS exige que o tráfego seja barrado antes de chegar à sua infraestrutura.
Minha hospedagem já tem WAF?
Provavelmente sim, se for uma hospedagem séria. A maioria mantém ModSecurity ou solução equivalente no servidor, aplicada a todas as contas sem configuração do cliente. Vale confirmar com o suporte — e é também a explicação para bloqueios aparentemente inexplicáveis, como um formulário que para de funcionar depois que você acrescenta um campo com código.
Por que o WAF bloqueou algo legítimo?
É um falso positivo: uma regra interpretou conteúdo válido como tentativa de ataque. O caso mais comum é salvar um post contendo código ou tags HTML e receber erro 403. A solução é pedir ao suporte o ajuste da regra específica, não desativar o WAF inteiro.
O que é o OWASP Core Rule Set?
É o conjunto de regras aberto mais usado em WAFs, mantido pela comunidade OWASP. Ele cobre as categorias de ataque mais frequentes contra aplicações web e serve de base para praticamente todas as soluções de WAF, que costumam complementá-lo com regras próprias e atualizações para vulnerabilidades novas.
Preciso de WAF se meu site é pequeno?
Sim, e o tamanho do site importa menos do que parece. Boa parte dos ataques não é direcionada: são bots varrendo a internet em busca de qualquer site com uma vulnerabilidade conhecida. A boa notícia é que, se você está em uma hospedagem com WAF de servidor, essa proteção básica já está ativa sem custo ou configuração adicional.
Veja também
Para entender a camada de rede, veja o que é firewall. Sobre segurança em WordPress especificamente, o guia do Wordfence mostra a configuração de um WAF em plugin. E para os conceitos gerais, veja segurança da informação e phishing.
Conclusão
Um WAF é o que permite bloquear um ataque que chega pela porta certa, com o protocolo certo, vindo de um IP sem histórico — porque ele olha o conteúdo, e não só o remetente. Isso o torna a peça central da proteção de um site, e complementar ao firewall de rede, não substituto. A pergunta que realmente importa na hora de escolher é onde ele roda: dentro do WordPress, no servidor ou na nuvem. Quanto mais cedo o filtro acontece, menos recursos o ataque consome antes de ser barrado — e é essa diferença que separa um site que resiste a um ataque de volume de um que fica fora do ar mesmo com o plugin de segurança funcionando.
