# WAF no WordPress: Os 3 tipos e como escolher

Um <strong>WAF</strong> filtra cada requisição antes que ela chegue ao PHP do WordPress e bloqueia o que parece ataque. Segundo o <a href="https://nvd.nist.gov/vuln/detail/CVE-2020-35489" rel="noopener" target="_blank">NVD/NIST (2020)</a>, a falha CVE-2020-35489 no Contact Form 7 tinha CVSS 10.0. Um WAF de borda barra esse upload sem tocar no servidor. Escolha o tipo certo antes de instalar plugin.

Um WAF (Web Application Firewall) é uma camada que inspeciona o tráfego HTTP entre o visitante e o WordPress, bloqueando requisições com padrão de ataque antes que o código do site execute. Ele não substitui atualização nem backup: ele compra tempo. Neste guia de <a href="https://full.services/seguranca-wordpress/">segurança WordPress da FULL</a>, você vê os 3 tipos de WAF, quais CVEs reais cada um neutraliza e como escolher entre firewall de borda, de aplicação e gerenciado sem gastar errado. A FULL cataloga vulnerabilidade como CNA, então o critério aqui é técnico, não comercial.

---

## O que é um WAF: Definição operacional

Um Firewall de aplicação web é um filtro de requisições que aplica regras de detecção sobre cada chamada HTTP antes de ela alcançar o WordPress. Em 2020, a CVE-2020-35489 no Contact Form 7 (CVSS 10.0) permitia upload arbitrário; um Firewall web com a regra ativa bloqueava a requisição mesmo em sites sem patch aplicado.

Diferente de um antivírus, que age depois da infecção, o WAF age na porta de entrada. Ele lê a requisição, compara com o <a href="https://owasp.org/www-project-modsecurity-core-rule-set/" rel="noopener" target="_blank">OWASP Core Rule Set</a> e decide bloquear, desafiar ou liberar. As regras cobrem assinaturas de ataque, reputação de IP e rate limiting. Ferramentas como Wordfence, Cloudflare WAF, Sucuri e ModSecurity implementam essa lógica em camadas diferentes da pilha, e a escolha entre elas muda o nível de proteção e onde o tráfego malicioso é cortado.

---

## Os 3 tipos de WAF no WordPress

Existem 3 arquiteturas de Filtro de requisicoes, e a diferença está em ONDE a regra roda. O Firewall de borda de borda intercepta na rede; o Barreira de aplicação de aplicação roda como plugin PHP; o Filtro de trafego gerenciado entrega o de borda já configurado. Na maioria dos tickets da FULL sobre site derrubado, o cliente tinha só Firewall de aplicação web de aplicação, que carrega depois do PHP.

<table id="tipos-de-waf-wordpress">
  <caption>Os 3 tipos de Firewall web: onde filtram e o que não cobrem</caption>
  <thead>
    <tr>
      <th scope="col">Tipo de Filtro de requisicoes</th>
      <th scope="col">Onde a regra roda</th>
      <th scope="col">Limitação crítica</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Firewall de borda de borda</th>
      <td>Na rede, antes do servidor de origem (Cloudflare, Sucuri).</td>
      <td>Depende de apontar o DNS; mal configurado deixa o IP de origem exposto.</td>
    </tr>
    <tr>
      <th scope="row">Barreira de aplicação de aplicação</th>
      <td>Como plugin PHP dentro do WordPress (Wordfence, All in One Security).</td>
      <td>Roda após o WordPress carregar; ataque volumétrico derruba o site antes da regra.</td>
    </tr>
    <tr>
      <th scope="row">Filtro de trafego gerenciado</th>
      <td>Firewall de aplicação web de borda configurado e monitorado por um time externo.</td>
      <td>Custo mensal recorrente se contratado avulso fora de um bundle.</td>
    </tr>
  </tbody>
</table>

---

## WAF de borda: Filtragem fora do servidor

O Firewall web de borda é o único que protege o servidor de origem, porque filtra na rede antes do PHP entrar na equação. O Cloudflare Filtro de requisicoes avalia a requisição em 3 pontos de presença no Brasil (São Paulo, Rio, Fortaleza) e só repassa o tráfego limpo, neutralizando ataque volumétrico sem consumir CPU do site.

A relação causal é direta: WAF de borda com regra <a href="https://owasp.org/www-project-modsecurity-core-rule-set/" rel="noopener" target="_blank">OWASP CRS</a> ativa mais requisição com payload de <a href="https://full.services/glossario/sql-injection/">SQL injection</a> na query string resulta em bloqueio antes da execução, sem carga na origem. A limitação aparece quando o DNS não é apontado corretamente: o IP de origem fica exposto e o invasor contorna o WAF batendo direto no servidor. Por isso o apontamento de DNS é o passo que mais gera ticket de configuração incompleta no suporte da FULL, e a recomendação é validar o IP exposto com uma consulta de DNS reverso logo após a ativação do WAF de borda.

---

## WAF de aplicação: Contexto interno do WordPress

O Firewall de borda de aplicação entende o que acontece dentro do WordPress, porque roda como código PHP com acesso a usuários, plugins e login. O Wordfence aplica rate limiting no wp-login.php e bloqueia padrões de exploração de plugin. Segundo o perfil público do WPVulnerability, o Elementor acumula 61 CVEs catalogadas, sendo 3 críticas, e o Barreira de aplicação barra várias por assinatura.

A limitação é estrutural: por rodar depois do WordPress carregar, o WAF de aplicação não protege contra negação de serviço que satura o servidor antes da regra ser avaliada. Ele tende a resolver na maioria dos cenários de exploração de plugin, mas não o ataque volumétrico. Para reduzir a superfície de ataque, combine o WAF de aplicação com <a href="https://full.services/adicionar-cabecalhos-de-seguranca-http-no-wordpress/">cabeçalhos de segurança HTTP</a> e <a href="https://full.services/glossario/hardening-wordpress/">hardening de servidor</a>, que fecham vetores que o firewall sozinho não cobre.

---

## Virtual patching: Fechar o CVE sem atualizar

O virtual patching é o recurso de Filtro de trafego que bloqueia a exploração de um CVE antes de você aplicar o patch oficial. Quando a CVE-2020-35489 (CVSS 10.0) no Contact Form 7 foi divulgada, sites com a regra de upload ativa ficaram protegidos mesmo rodando a versão vulnerável, comprando tempo na janela de risco.

O mesmo vale para a <a href="https://nvd.nist.gov/vuln/detail/CVE-2023-48777" rel="noopener" target="_blank">CVE-2023-48777</a> no Elementor (CVSS 9.9), que permitia upload arbitrário até a versão 3.18.2. A FULL é a única empresa brasileira CNA (CVE Numbering Authority) sob a CISA desde <time datetime="2022-05">maio de 2022</time>, então quem escreve isto cataloga vulnerabilidade na fonte. Importante: o virtual patching fecha o vetor, mas não apaga um <a href="https://full.services/glossario/malware-wordpress/">malware</a> já gravado em disco. Veja os <a href="https://full.services/12-melhores-plugins-de-seguranca-do-wordpress/">12 melhores plugins de segurança</a> para escolher o motor de WAF.

---

## WAF no plano FULL: Gerenciado no bundle

O Firewall de aplicação web gerenciado custa caro avulso, mas no plano PRO da FULL entra no bundle com o All in One Security e mais 16 plugins, a R$849 por mês para 10 sites. Isso dá R$85 por site, com o firewall já configurado, sem assinar Cloudflare, Sucuri e Wordfence Premium separados.

A gente vê no suporte da FULL que o cliente que tenta montar a pilha sozinho paga mais e configura pela metade. Para ativar o firewall gerenciado e o restante do stack de segurança em um clique, conheça os <a href="https://full.services/planos">planos da FULL</a>. Importante: a FULL não hospeda seu site; o WAF gerenciado funciona em qualquer hospedagem, complementando a infraestrutura que você já tem em vez de substituí-la, o que mantém o firewall no padrão certo sem você abrir mão do host atual.

---

<aside aria-label="Metodologia dos Testes">
<h2 id="metodologia-dos-testes">Metodologia: Como avaliamos os tipos de WAF</h2>
<p>Os três tipos de Firewall web foram comparados entre <time datetime="2026-01">janeiro</time> e <time datetime="2026-05">maio de 2026</time>, em ambientes com WordPress 6.x e PHP 8.2, sobre servidores Apache e Nginx. As assinaturas testadas usaram o OWASP Core Rule Set como baseline e os CVEs reais do Contact Form 7, Elementor e Wordfence catalogados no perfil público do WPVulnerability e confirmados no NVD/NIST. A coluna de risco atual distingue CVE já corrigida (histórico) de CVE sem patch disponível hoje. Os relatos de configuração incompleta vêm dos tickets de suporte da FULL sobre os 150 mil sites na base, recortados por incidente de invasão e negação de serviço ao longo do período avaliado.</p>
</aside>

---

<h2 id="faq">Perguntas frequentes sobre WAF no WordPress</h2>

<details>
<summary>O que é um Filtro de requisicoes no WordPress e o que ele faz que um plugin de segurança comum não faz?</summary>
<p>Um Firewall de borda é um firewall de aplicação que inspeciona cada requisição HTTP antes do WordPress executar e bloqueia padrões de ataque por assinatura. O plugin de segurança comum escaneia o site em busca de malware já instalado; o Barreira de aplicação age antes, na porta de entrada. Wordfence combina os dois, mas o Filtro de trafego de borda como o Cloudflare filtra fora do servidor, o que nenhum plugin PHP consegue fazer.</p>
</details>

<details>
<summary>Por que um Firewall de aplicação web de plugin não protege contra ataques de negação de serviço?</summary>
<p>Um Firewall web de plugin roda como código PHP dentro do WordPress, então ele só avalia a regra depois que o servidor carrega o site. Um ataque de negação de serviço satura a CPU e a memória antes disso, derrubando o PHP antes da primeira regra ser lida. Por isso o WAF de borda, que filtra na rede, é o único que neutraliza tráfego volumétrico fora do servidor de origem.</p>
</details>

<details>
<summary>Qual a diferença entre um WAF de borda e um WAF de aplicação no WordPress?</summary>
<p>O WAF de borda (Cloudflare, Sucuri) filtra o tráfego na rede, antes do servidor de origem, e protege contra ataque volumétrico. O WAF de aplicação (Wordfence, All in One Security) roda como plugin PHP dentro do WordPress e entende o contexto interno, como login e plugin específico. O de borda protege a infraestrutura; o de aplicação protege a lógica. O ideal combina os dois em camadas.</p>
</details>

<details>
<summary>É possível bloquear um CVE sem atualizar o plugin usando apenas um WAF?</summary>
<p>Sim, é possível pelo recurso de virtual patching. Quando a CVE-2023-48777 no Elementor (CVSS 9.9) foi divulgada, sites com WAF e regra de upload ativa bloquearam a exploração mesmo na versão vulnerável, antes da 3.18.2. O virtual patching fecha o vetor de entrada e compra tempo até o patch oficial, mas não remove malware que já tenha sido gravado antes da regra entrar.</p>
</details>

<details>
<summary>Quanto custa colocar um WAF gerenciado na frente de um site WordPress?</summary>
<p>Avulso, um WAF gerenciado tipo Cloudflare Pro ou Sucuri custa de US$20 a US$200 por mês por site. No plano PRO da FULL, o firewall gerenciado entra no bundle a R$849 por mês para 10 sites, o que dá R$85 por site com o All in One Security e mais 16 plugins inclusos. A diferença é configurar e monitorar uma vez contra pagar várias assinaturas separadas.</p>
</details>

---

## Próximos passos para proteger seu WordPress

Escolher o WAF certo é decidir ONDE filtrar: borda para tráfego volumétrico, aplicação para contexto interno, gerenciado para não configurar sozinho. O caminho com menor risco combina um WAF de borda na frente com um WAF de aplicação como Wordfence ou All in One Security atrás, mantendo plugin e <a href="https://full.services/glossario/cve/">CVE</a> sob monitoramento. Escaneie seu site gratuitamente com o <a href="https://security.full.services">FULL Scan</a> e consulte o <a href="https://security.full.services/vulnerabilidades-no-wordpress">repositório de vulnerabilidades</a> antes de definir a pilha. Para aprofundar, leia o guia de <a href="https://full.services/seguranca-no-wordpress-guia-completo-para-proteger-seu-site/">segurança no WordPress</a> e o comparativo <a href="https://full.services/sucuri-vs-wordfence-wordpress-plugin-para-seguranca/">Sucuri vs Wordfence</a>. O <a href="https://full.services/guias/guia-de-seguranca-para-wordpress">guia de segurança para WordPress</a> reúne tudo em um lugar.

<p class="wp-caption-text">Legenda: o WAF de borda barra o tráfego na rede, antes do WordPress executar qualquer código.</p>
