Um firewall WordPress filtra o tráfego malicioso antes do ataque chegar ao site, na borda ou via plugin. Segundo o OWASP Top 10 (2021), 94% das aplicações testadas tinham falha de controle de acesso. O WAF de borda barra fora do PHP; o de plugin, dentro. Nenhum dispensa backup testado.

Um firewall WordPress é a camada que inspeciona cada requisição e bloqueia a que tem padrão de ataque antes que ela faça estrago. A gente vê no suporte da FULL que a dúvida certa não é se precisa de firewall, e sim em que ponto ele atua: na borda, antes do site, ou dentro do WordPress, junto do PHP. Esse detalhe muda tudo, do consumo de CPU à capacidade de barrar uma falha sem patch. Este conteúdo faz parte dos guias de segurança WordPress da FULL e explica os tipos de firewall, o que cada um barra e quando ele simplesmente não basta para manter o site protegido.

O que é um firewall WordPress na prática

Um firewall WordPress, ou WAF (Web Application Firewall), é o filtro que lê cada requisição HTTP e bloqueia a que bate com regras de ataque conhecidas, como tentativa de SQL injection ou upload de arquivo malicioso. Ele não é antivírus nem backup: age na entrada, antes do dano.

Na prática, o firewall compara o tráfego com uma base de assinaturas e comportamentos suspeitos. Quando um IP tenta 200 logins em um minuto, ou injeta código numa URL, a regra dispara e a requisição morre ali. Segundo o OWASP Top 10 (2021), 94% das aplicações testadas tinham falha de controle de acesso, ou seja, a maioria das invasões explora configuração mal feita, não bug exótico. É exatamente esse tipo de abuso de regra que o firewall foi feito para barrar, funcionando como primeira linha antes das outras camadas de defesa do site.

WAF de borda contra firewall de plugin

A distinção que mais confunde é o lugar onde o ataque é barrado, e ela define até o consumo de CPU do servidor: o WAF de borda filtra na nuvem, antes da requisição tocar o site; o firewall de plugin roda dentro do WordPress, depois que o PHP já carregou.

O firewall de borda, como o da Cloudflare ou o do Sucuri, intercepta o tráfego no caminho até o servidor. A requisição maliciosa nem chega a consumir recurso do site, o que tende a aliviar a hospedagem em ataques de volume. Já o firewall de plugin, como o do Wordfence, mora junto da aplicação: a requisição já acionou o PHP antes de ser bloqueada, gastando processamento. Em servidor compartilhado modesto, isso aparece como lentidão durante picos de ataque. Os dois não competem, eles se somam: a borda absorve o volume bruto, o plugin faz a inspeção fina dentro do WordPress, junto da varredura de arquivos.

Tipos de firewall e o que cada um barra

São três modelos de firewall WordPress que cobrem camadas diferentes, e confundir um com o outro é o erro mais comum de quem só instala o plugin mais famoso. A tabela abaixo separa cada tipo pelo ponto de atuação, pelo que barra melhor e pela limitação que pesa na escolha.

Legenda: cada camada barra um tipo diferente de ataque, por isso a proteção real vem da soma, não de um firewall só.

Por que o firewall depende de CVE e versão

O firewall não adivinha ataques novos: ele depende de regras atualizadas contra vulnerabilidades reais, e é aqui que a versão do plugin vira o ponto fraco. Uma falha catalogada como CVE entra na base do firewall, mas só protege se a regra estiver ativa antes do exploit.

Um exemplo concreto: o Contact Form 7 abaixo da versão 5.3.2 aceitava upload de arquivo sem validar o tipo, o que permitia subir um PHP malicioso. Essa falha virou o CVE-2020-35489, com CVSS 10.0, o teto da escala, segundo a base oficial do NVD (NIST). Um firewall com regra virtual barra esse padrão de upload mesmo antes do site atualizar o plugin. Sem a regra, a única defesa é o patch. A FULL é a única CNA brasileira sob a CISA desde maio de 2022, então a régua de severidade aqui é a de quem atribui o ID CVE, não a de quem só lê o aviso.

Virtual patching: Proteção antes do patch

O recurso mais subestimado do firewall WordPress é o virtual patching, a regra que bloqueia a exploração de uma falha enquanto o patch oficial ainda não saiu ou não foi aplicado. Ele compra tempo, e tempo é o que falta quando um CVE crítico vira público.

Quando uma vulnerabilidade é divulgada, os bots começam a varrer a web em busca de sites desatualizados em horas, não dias. O firewall com virtual patching reconhece o padrão do exploit e o derruba na entrada, mesmo com o plugin ainda na versão vulnerável. A gente vê no suporte da FULL que a janela entre a divulgação de um CVE e o site aplicar o update é justamente onde a maioria das invasões acontece. Por isso o firewall tende a importar mais para quem demora a atualizar do que para quem mantém tudo em dia, ainda que cada vulnerabilidade exija o patch real no fim.

Quando o firewall não basta para proteger

Em três cenários o firewall WordPress não resolve o problema e ainda dá falsa sensação de blindagem, segundo o que a gente acompanha de perto no suporte da FULL ao longo do ano. Reconhecer esses limites evita o erro de achar que firewall ligado é site invulnerável.

O primeiro cenário é o site já comprometido: firewall instalado depois da invasão não limpa o malware que já está dentro, só monitora dali pra frente. O segundo é a hospedagem sem isolamento, onde um site vizinho contaminado infecta o seu por baixo do firewall. O terceiro é a falta de backup: o firewall avisa do ataque, mas sem cópia limpa para restaurar, a recuperação vira reconstrução. Por isso o backup automático do WordPress pesa tanto quanto o firewall, e a defesa real contra ataques de força bruta combina as duas coisas com hardening de configuração.

Quanto custa um firewall gerenciado no WordPress

A conta que decide o firewall é o custo de recuperar um site invadido contra o de manter a borda já ativa: um WAF de nuvem avulso parte de US$199 por ano no Sucuri, enquanto a base gerenciada da FULL sai por R$85 por site no plano PRO, com firewall e backup inclusos.

A gente vê no suporte da FULL que a limpeza de malware e o tempo de site fora do ar pesam mais que qualquer licença anual de firewall. Na plataforma gerenciada da FULL, a partir de R$849 no plano PRO, o firewall de borda já vem ativo, o backup diário roda automático e o All in One Security PRO vem instalado e atualizado, com custo diluído de R$85 por site no bundle. O All in One Security entra como camada de hardening gerenciada, e o plano completo está em FULL.services/planos. O firewall segue sendo o filtro de entrada; a base é o que impede o estrago quando algo passa.

Perguntas frequentes sobre firewall WordPress

O caminho para proteger o site em camadas

Entender o firewall WordPress é menos sobre escolher a marca famosa e mais sobre saber onde o ataque é barrado: na borda, no plugin ou no servidor. O WAF de nuvem absorve volume e força bruta antes do PHP, o firewall de plugin faz a inspeção fina de arquivos, e o virtual patching segura a falha enquanto o patch não chega. Mas o ponto que mais gente ignora é que nenhum firewall substitui a base: hospedagem isolada e backup testado decidem se o site sobrevive a uma falha nova. A FULL é a única CNA brasileira sob a CISA, e a leitura que a gente faz no suporte é sempre a mesma, segurança boa é em camadas. Compare os firewalls líderes em Sucuri vs Wordfence, ajuste o seu em configuração do Wordfence e entenda onde o plugin não basta em plugin de segurança WordPress. Para barrar tentativas de invasão, veja como evitar ataques de força bruta no login e cheque CVEs por componente com ferramentas para verificar vulnerabilidades. Comece rodando o FULL Scan de graça, consulte o repositório de vulnerabilidades e continue no guia de segurança para WordPress e no FULL Academy.