O hardening de segurança WordPress é o processo de reduzir a superfície de ataque do site em camadas independentes, e não a instalação de um único plugin. A diferença importa: um firewall bloqueia o payload quando ele chega, mas o hardening remove o vetor antes que o payload exista. Um site com Wordfence ativo ainda é invadido se o wp-config.php roda com chaves default e o XML-RPC continua aberto. Este guia mostra as 7 camadas que blindam o WordPress sem quebrar o painel, com comandos reais, valores padrão de cada ajuste e o ponto exato onde cada configuração entra. O objetivo é prático: você termina com um checklist aplicável hoje, do servidor ao login. Para o panorama completo, veja o guias de segurança WordPress da FULL.

Diagnóstico rápido: O que o hardening de segurança WordPress cobre

O hardening de segurança WordPress cobre sete camadas, e cada uma fecha um vetor distinto que um plugin sozinho não resolve. Em 2024, o XSS respondeu por 53% das vulnerabilidades divulgadas, segundo o WPScan, sinal de que o problema raramente mora no core, e sim em código de terceiros e em configuração frouxa.

A tabela abaixo organiza as sete camadas por prioridade de aplicação, com o objetivo de defesa e o check de validação de cada uma. A ordem reflete a profundidade do vetor: o que está mais próximo do servidor entra primeiro.

A ordem importa: começar pelo firewall sem fechar o wp-config.php deixa o WAF na frente de uma porta já destrancada. Nos tickets da FULL, a maioria dos sites reinvadidos tinha plugin de segurança, mas nunca passou pelas camadas de configuração.

Por que o hardening de segurança WordPress vem antes do plugin

O hardening de segurança WordPress precede o plugin porque ele elimina o vetor, enquanto o plugin apenas reage ao ataque em andamento. Um WAF como o Wordfence inspeciona a requisição e bloqueia padrões conhecidos, mas não regenera uma chave AUTH_KEY previsível nem corrige uma das 7 camadas mal configuradas, como permissão 777 em wp-content.

A relação causal é direta: AUTH_KEY e SALT default no wp-config.php somados a um cookie de sessão gerado com chave previsível resultam em forja de sessão admin válida, sem o invasor passar pelo formulário de login uma única vez. O firewall não vê esse ataque, porque ele não dispara nenhum payload suspeito. Por isso a sequência correta trata a configuração primeiro e o plugin como camada de reforço, nunca como a primeira linha. Quem inverte a ordem tende a pagar caro: na maior parte dos casos de suporte, o site com WAF e configuração frouxa volta a ser comprometido em dias.

Passo a passo: Hardening de segurança WordPress do servidor ao login

O passo a passo do hardening de segurança WordPress segue do nível mais profundo, o servidor e o wp-config.php, até o login, que é o ponto mais atacado. Cada uma das 4 etapas abaixo é independente e validável em poucos minutos.

Aplique na ordem apresentada, porque cada camada assume que a anterior já está fechada. Um ajuste mal sequenciado, como ativar o WAF antes de regenerar as chaves, mantém o vetor aberto por trás do firewall.

Passo 1: Regenere as chaves de segurança do wp-config.php

Abra o wp-config.php e substitua as oito constantes AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY e seus respectivos SALTs por valores gerados na API oficial em https://api.wordpress.org/secret-key/1.1/salt/. Chaves default permitem forjar cookies de sessão. Após colar os novos valores, todas as sessões ativas caem e exigem novo login, o que expulsa qualquer sessão sequestrada. Adicione também define('DISALLOW_FILE_EDIT', true); para desativar o editor de plugins e temas dentro do painel. Detalhes em como proteger o wp-config.php no WordPress.

Passo 2: Ajuste as permissões de arquivos e pastas

Defina 644 para arquivos e 755 para pastas, e nunca deixe wp-config.php acima de 640. Permissão 777 em wp-content combinada com upload sem validação de tipo gera um webshell PHP executável direto do navegador, sem credencial. No terminal, rode find . -type f -exec chmod 644 {} ; e find . -type d -exec chmod 755 {} ; a partir da raiz do site. Confirme depois que nenhuma pasta ficou gravável por todos.

Passo 3: Limite tentativas de login e ative o 2FA

Instale um plugin que limite tentativas de login a 5 falhas antes do bloqueio temporário e ative a autenticação de dois fatores no painel admin. Login sem limite somado a senha reciclada de vazamento público resulta em sucesso de força bruta automatizada em minutos. Veja o detalhamento em como evitar ataques de forca bruta no login e em como ativar a autenticacao de dois fatores.

Passo 4: Feche o xml-rpc e a enumeracao de usuários

Fechar o XML-RPC é o passo do hardening de segurança WordPress que mais corta reconhecimento automatizado. Desative o XML-RPC se você não usa o app móvel nem pingbacks, porque ele permite amplificar força bruta testando centenas de senhas por requisição. Bloqueie a enumeração de usuários via /?author=1, que entrega nomes de login válidos. No .htaccess, negue acesso ao xmlrpc.php e redirecione tentativas de enumeração. Esses dois ajustes cortam dois dos vetores de reconhecimento mais usados por bots.

Camada de rede: Firewall, cabeçalhos HTTP e HTTPS

A camada de rede do hardening de segurança WordPress adiciona um filtro antes da aplicação receber a requisição, e responde por boa parte dos ataques bloqueados em produção. Um WAF como o Cloudflare ou o Wordfence aplica regras no padrão OWASP que barram tentativas de SQL injection e de XSS, que sozinho respondeu por 53% das vulnerabilidades divulgadas em 2024 segundo o WPScan.

Os cabeçalhos HTTP fecham a camada do navegador: HSTS força HTTPS, X-Frame-Options impede clickjacking e a Content-Security-Policy restringe scripts a origens confiáveis. Configure o HTTPS com certificado válido antes de ativar o HSTS, porque o HSTS torna o HTTPS obrigatório e um certificado quebrado deixa o site inacessível. A ordem recomendada é certificado, redirecionamento 301 para HTTPS, e só então o cabeçalho HSTS com max-age progressivo. Para o passo a passo, consulte como adicionar cabeçalhos de segurança HTTP. A REST API também merece atenção: restrinja endpoints sensíveis conforme o guia de proteção da REST API.

Atualizações e gestão de patches: Fechando o CVE antes da exploracao

A gestão de patches do hardening de segurança WordPress mantém core, plugins e temas em versões sem CVE conhecido, e esse é o vetor que mais escala. Como 96% das vulnerabilidades de 2024 estavam em plugins, segundo o WPScan, manter o inventário enxuto reduz a superfície de forma direta: cada plugin desinstalado é um vetor a menos.

A relação causal é cruel: um plugin desatualizado com CVE público somado à ausência de WAF resulta em exploração automatizada do payload em horas após a divulgação. Habilite atualizações automáticas para releases de segurança do core e revise plugins abandonados, que não recebem patch. Rode um scan de vulnerabilidades periódico para confirmar que nenhum CVE ficou aberto. O passo a passo de verificação está em como verificar vulnerabilidades no WordPress. Ferramentas como WPScan e Wordfence cruzam a versão instalada com a base de CVEs e apontam o que precisa de patch imediato.

Backup e plano de recuperação: A camada que reduz o custo da falha

O backup do hardening de segurança WordPress não impede o ataque, ele reduz o custo quando as camadas anteriores falham, e por isso fecha a lista das 7. Um backup útil é diário, automatizado, armazenado offsite e, principalmente, testado: restauração nunca validada em staging não é backup, é esperança.

A regra prática é manter pelo menos três cópias, em dois meios diferentes, com uma fora do servidor de produção. Configure a retenção para cobrir o tempo entre o comprometimento e a detecção, que pode passar de uma semana em sites sem monitoramento. Quando o site é invadido, um backup íntegro anterior à infecção transforma um incidente de dias em uma restauração de minutos. Para automatizar isso sem depender de lembrete manual, veja como configurar backup automático no WordPress. O plano de recuperação também precisa de um runbook: quem restaura, de onde, e como confirmar que a infecção não voltou junto.

Quanto custa blindar o WordPress com a FULL

Manter as 7 camadas atualizadas exige plugins PRO de segurança, backup e firewall, e é aí que o custo avulso pesa. No plano PRO da FULL, por R$849, você ativa o bundle completo com All in One Security, UpdraftPlus e os demais plugins premium em até 10 sites, o que dá R$85 por site.

A conta fecha rápido: licenças avulsas de firewall, backup e otimização passam de R$85 por site só somando três ferramentas. A gente vê no suporte da FULL que o cliente que centraliza as camadas em um bundle único mantém o hardening em dia, porque não precisa renovar cinco licenças separadas. Conheça os planos em FULL.services/planos.

Legenda: o painel reúne as camadas de hardening em um único fluxo, do wp-config ao firewall.

Para escanear o site agora e descobrir se algum plugin está vulnerável, use o FULL Scan gratuitamente, sem instalação. Quem precisa consultar um CVE específico encontra o catálogo completo no repositorio de vulnerabilidades da FULL, atualizado com dados oficiais. Para aprofundar cada camada, o guia de segurança para WordPress reúne os tutoriais em sequência.

Perguntas frequentes sobre hardening de segurança WordPress

Próximos passos para manter o WordPress blindado

O hardening de segurança WordPress não é um projeto único, é uma rotina de manutenção que mantém as 7 camadas em dia conforme novos CVEs surgem. Comece hoje pelas duas camadas de maior retorno, o wp-config.php e o login, que respondem pela maior parte das invasões automatizadas. Depois suba para a rede, com firewall e cabeçalhos HTTP, e feche com backup testado. Reescaneie o site mensalmente para confirmar que nenhum plugin abriu um vetor novo. Para continuar aprendendo, o FULL Academy reúne os tutoriais, guias e reviews de segurança em um só lugar, na sequência certa para aplicar sem quebrar nada.