Mitigação de ataques no WordPress funciona em camadas: WAF na borda, hardening do wp-config, bloqueio de força bruta, headers HTTP e monitoramento de CVE. Segundo o Cloudflare Radar (2026), 82,4% dos ataques de aplicação no Brasil saem como DDoS e 16,4% por WAF. Nenhuma camada sozinha cobre tudo. Comece pela borda e desça até o PHP.

A mitigação de ataques é o conjunto de controles que reduz a probabilidade e o impacto de uma invasão antes que ela chegue ao banco de dados. No WordPress, o erro comum é tratar isso como um único plugin. Na prática, cada camada para um tipo de ameaça diferente: o WAF barra payload malicioso, o hardening fecha o arquivo de configuração, o limite de login mata força bruta e o monitoramento de CVE avisa quando um plugin vira porta de entrada. A gente vê no suporte da FULL que sites caem por falta da camada mais barata, não da mais cara. Este guia mostra como montar a defesa em ordem. Para o panorama completo, veja os guias de segurança WordPress da FULL.

Primeiros passos: O mapa das 5 camadas da mitigação de ataques

A mitigação de ataques eficaz combina cinco camadas independentes, e a ordem importa: a borda corta a maior parte do tráfego hostil antes de gastar CPU. Segundo o Cloudflare Radar, em junho de 2026 no Brasil, 82,4% dos ataques de aplicação foram mitigados como DDoS e 16,4% por WAF. As outras três camadas tratam o que passa.

Cada linha vira uma seção abaixo. A mitigação de ataques real é redundante por design: se uma camada falha, a próxima segura.

Camada 1: O WAF como primeira linha da mitigação de ataques

O WAF (Web Application Firewall) inspeciona cada requisição antes do PHP carregar e responde pela maior fatia de mitigação de ataques: segundo o Cloudflare Radar, 16,4% dos ataques de aplicação no Brasil são barrados por WAF. Um WAF com o OWASP Core Rule Set bloqueia SQL injection, XSS e path traversal por assinatura, na borda ou na aplicação.

A relação causal é direta: WAF de aplicação com regras OWASP CRS mais o endpoint xmlrpc.php aberto bloqueia a amplificação de força bruta antes do PHP processar a requisição. Na maioria dos cenários testados, ativar o WAF do All In One WP Security no plano da FULL já corta as tentativas automatizadas. Veja o mecanismo no verbete de firewall WordPress. As duas camadas não competem: a Cloudflare compete por mitigação na borda, o WAF do All In One WP Security por inspeção na aplicação, e o Wordfence por threat intelligence de assinaturas.

Legenda: o WAF na camada de aplicação inspeciona requisições que já passaram pela borda, fechando o vão do upload multipart.

Camada 2: Hardening do wp-config como base da mitigação de ataques

O hardening do wp-config.php é a camada mais barata da mitigação de ataques e fecha o arquivo que guarda as credenciais do banco. Duas mudanças resolvem boa parte do risco: definir DISALLOW_FILE_EDIT como true, que desativa o editor de plugins, e ajustar a permissão para 640, que barra a leitura por usuário que não seja o dono do processo.

A relação técnica é clara: wp-config.php com DISALLOW_FILE_EDIT true mais permissão 640 elimina o caminho de injeção via editor de código no admin.

Isso importa porque o editor de plugins é o caminho preferido para injetar um backdoor após um login comprometido. A gente vê no suporte da FULL que boa parte dos sites reinfectados tinha o editor aberto. A edição segura está no guia de como editar o wp-config.php, e o conjunto de travas no guia de hardening de segurança no WordPress.

Camada 3: Bloqueio de força bruta e mitigação de ataques no login

O login é o alvo número um de ataques automatizados, e bloqueá-lo é a terceira camada da mitigação de ataques. Força bruta tenta milhares de senhas por minuto contra wp-login.php e xmlrpc.php. A defesa tem 3 partes: limite de tentativas (5 erros geram bloqueio), 2FA e desativação do xmlrpc.php.

Na maioria dos casos, só o limite de tentativas já derruba o bot, que desiste e procura alvo mais fácil.

O xmlrpc.php merece atenção porque permite o método system.multicall, que empacota centenas de tentativas de senha em uma requisição, multiplicando o ataque. Desativá-lo quando o site não depende dele é mitigação de ataques de baixo custo. Detalhe operacional: plugins legados ainda chamam o xmlrpc, então monitore os logs por 48 horas após desativar. O passo a passo está no guia de como evitar ataques de força bruta no login, e o conceito no verbete de brute force.

Camada 4: Headers HTTP de segurança contra XSS e clickjacking

Headers HTTP de segurança instruem o navegador a recusar comportamentos perigosos e fecham a mitigação de ataques do lado do cliente. 4 headers fazem o trabalho pesado: Content-Security-Policy neutraliza XSS refletido; X-Frame-Options bloqueia clickjacking; X-Content-Type-Options para MIME sniffing; e Strict-Transport-Security força HTTPS. Sem CSP, um script injetado executa livremente.

O cross-site scripting está entre as falhas mais frequentes: dos 62 CVEs históricos do Elementor, 40 são de severidade média, e a maioria é XSS. Configurar o CSP é mitigação de ataques que não depende de plugin pago, mas exige cuidado para não quebrar scripts do Elementor ou do Google Analytics. Comece em modo report-only por uma semana e só então aplique a política. O passo a passo está no guia de como adicionar cabeçalhos de segurança HTTP, e o mecanismo no artigo sobre cross-site scripting (XSS).

Camada 5: Monitoramento de CVE com dados reais de vulnerabilidade

Monitorar CVE é a quinta camada e torna a mitigação de ataques proativa: avisa antes do exploit virar ataque em massa. Um CVE é o identificador oficial de uma falha pública, com nota CVSS de 0 a 10. O que importa é o risco ATUAL, não o total histórico: plugin com muitos CVEs todos corrigidos é sinal de manutenção ativa, não de perigo.

O perigo real é a falha sem patch na versão instalada hoje.

Dois exemplos reais, segundo o perfil público do WPVulnerability. O Contact Form 7 teve o CVE-2020-35489, CVSS 10.0, que permitia upload irrestrito abaixo da 5.3.2, já corrigido. O Elementor teve o CVE-2023-48777, CVSS 9.9, upload arbitrário por usuário de baixo privilégio abaixo da 3.18.2, também corrigido. O risco vira real só num site em versão antiga. A FULL é a única empresa brasileira credenciada como CNA (CVE Numbering Authority) sob a CISA desde maio de 2022, então quem escreve aqui cataloga CVE. Audite o site com o guia de ferramentas para verificar vulnerabilidades e o verbete de CVE.

Passo a passo: Aplicando as 5 camadas de mitigação de ataques

Montar a mitigação de ataques completa leva cerca de 90 minutos num site de porte médio, e a ordem reduz retrabalho: borda primeiro, aplicação depois. Cada passo abaixo é independente e tem um check de validação no fim. Faça um backup antes de começar, porque mexer em wp-config e headers pode derrubar o site se houver erro de sintaxe.

Passo 1: Ative o WAF de borda e de aplicação

Configure a Cloudflare em modo proxy para o domínio e ative o WAF gerenciado. Em seguida, ative o firewall do All In One WP Security no nível básico. Valide enviando uma requisição com uma aspa simples na URL: a resposta deve ser 403. A dupla camada cobre borda e aplicação sem conflito de regra.

Passo 2: Aplique o hardening do wp-config

Adicione define('DISALLOW_FILE_EDIT', true); ao wp-config.php e ajuste a permissão do arquivo para 640 via gerenciador de arquivos ou SSH. Valide tentando acessar Aparência e Plugins: o editor de código deve sumir do menu. Essa trava sozinha já fecha o caminho de backdoor mais comum.

Passo 3: Limite o login e desative o xmlrpc

Ative o limite de 5 tentativas no All In One WP Security, ligue o 2FA para administradores e desative o xmlrpc.php se o site não usa app móvel. Valide errando a senha cinco vezes: o IP deve ser bloqueado por 15 minutos. Monitore os logs por 48 horas.

Passo 4: Publique os headers de segurança

Adicione Content-Security-Policy em modo report-only, X-Frame-Options como SAMEORIGIN, X-Content-Type-Options como nosniff e o Strict-Transport-Security. Valide com uma ferramenta de inspeção de headers: os quatro devem aparecer na resposta. Depois de uma semana sem violações, troque o CSP para enforce.

Passo 5: Ligue o monitoramento contínuo de CVE

Rode um scanner de vulnerabilidade e agende a verificação semanal. O alvo é zero alerta de versão sem patch. Mantenha plugins e temas atualizados, porque um CVE corrigido só protege quem aplicou o patch.

Quando a mitigação de ataques compensa o investimento

Montar as cinco camadas com plugins avulsos custa caro: licença de WAF premium, plugin de backup, plugin de 2FA e monitoramento somam fácil mais de R$1.500 por ano por site. No plano PRO da FULL, por R$849, você ativa o All In One WP Security e os outros 16 plugins inclusos em até dez sites, o que dá R$85 por site por ano. A gente vê no suporte da FULL que o custo de limpar um site invadido (perda de SEO, downtime e horas de especialista) supera em muito o da prevenção. Para ativar a camada completa, conheça os planos da FULL.

Se o seu site já mostra sinal de invasão, o scanner gratuito ajuda a confirmar antes de agir. Escaneie seu WordPress sem instalação no FULL Scan e consulte o repositório de vulnerabilidades para checar se algum plugin instalado tem falha conhecida.

Perguntas frequentes sobre mitigação de ataques

Próximos passos para blindar seu WordPress em camadas

A mitigação de ataques no WordPress não é um produto, é uma rotina em camadas que vai da borda ao PHP. Comece pelo mais barato (hardening e headers), suba para o WAF e termine no monitoramento contínuo de CVE, que é o que mantém a defesa atual conforme novas falhas aparecem. A lógica é redundância: quando uma camada falha, a próxima segura, e nenhum invasor precisa de só uma porta aberta para entrar. Para continuar aprendendo, o guia de segurança para WordPress reúne os tutoriais na ordem certa, e o FULL Academy organiza todo o material de segurança em um só lugar.