# Hardening WordPress: O guia em 7 camadas de defesa Hardening reduz a superfície de ataque do WordPress em camadas, antes do invasor encontrar uma brecha. Segundo a Patchstack (2024), surgiram 7.966 vulnerabilidades no ecossistema em 2024, 96% delas em plugins. Não é instalar um plugin: é configuração, permissão e patch somados. Comece pelo wp-config.php e pelo login. Hardening é o processo de fechar os vetores de ataque do WordPress antes que alguém os explore, somando configuração de servidor, permissões de arquivo, atualização de plugins e controle de acesso ao login. A palavra vem de "endurecer": você não adiciona uma defesa mágica, você remove cada porta que não precisa estar aberta. No suporte da FULL, a gente vê que a maioria dos sites invadidos tinha um plugin de segurança ativo, mas continuava com a configuração padrão do wp-config.php intacta. Este guia abre o tema em camadas e linka o guias de segurança WordPress da FULL para cada etapa. --- ## O que é hardening no WordPress: Definição operacional Hardening no WordPress é a redução metódica da superfície de ataque, distribuída em camadas que se sobrepõem: servidor, arquivos, banco, login e aplicação. Na maioria dos chamados de invasão no suporte da FULL (base de 150 mil sites), a falha não estava no plugin de segurança ausente, mas numa camada de configuração que ninguém revisou. Não é um produto, é disciplina recorrente. A diferença prática importa porque muda onde você investe esforço. Um firewall WAF bloqueia o payload na borda; o hardening de configuração elimina o vetor antes que exista payload para bloquear. As duas abordagens são complementares, não substitutas. Um site com Wordfence ativo, mas com AUTH_KEY default e permissão 777 em wp-content, está com o segurança na porta da frente enquanto a porta dos fundos segue destrancada. O objetivo do hardening é trancar todas elas, na ordem certa.

Legenda: cada camada do hardening fecha um vetor distinto; sozinha, nenhuma protege o site por inteiro.

## Por que o plugin de segurança sozinho não basta Um plugin de segurança resolve só uma fração do problema porque atua na camada de aplicação, e a maioria das invasões entra por outra. Segundo a Patchstack, 96% das 7.966 vulnerabilidades de 2024 estavam em plugins de terceiros, não no núcleo. Um WAF não corrige permissão de arquivo errada nem troca chave secreta previsível: só intercepta requisição que passa por ele. O ponto cego aparece quando o invasor não precisa de requisição suspeita: se o cookie de sessão usa a AUTH_KEY default do wp-config.php, ele forja uma sessão de admin válida sem tocar no login. A tabela abaixo mapeia as 7 camadas, o vetor que cada uma fecha e a ferramenta típica.
Hardening WordPress: 7 camadas, vetor fechado e ferramenta
Camada Vetor que fecha Ferramenta típica
Servidor e PHPVersão obsoleta com CVE conhecidoPHP 8.2, painel da hospedagem
wp-config.phpChaves default e forja de cookieGerador de salts oficial
Permissões de arquivoWebshell via upload sem validaçãochmod 644/755, painel
Login e acessoForça bruta e credencial fraca2FA, All in One Security
Plugins e temasCVE não corrigidoWordfence, atualização gerenciada
Firewall WAFPayload em tempo de execuçãoCloudflare, Wordfence
MonitoramentoPersistência após invasãoScanner de integridade, backup
## Camada 1: Hardening do wp-config.php em 4 ajustes O wp-config.php é a primeira camada porque concentra as chaves que autenticam toda sessão do site. Quatro ajustes fecham os vetores mais explorados: trocar as 8 chaves de SALT pelo gerador oficial, mover o arquivo um nível acima da raiz web, definir `DISALLOW_FILE_EDIT` como `true` e restringir a permissão para 600. A relação causal é mensurável: AUTH_KEY e SALT default somados a um cookie de sessão previsível resultam em forja de sessão de administrador válida, sem passar pelo login, o que torna 2FA e limite de tentativas irrelevantes. Trocar as chaves invalida toda sessão ativa na hora, então faça fora do horário de pico. Bloquear a edição de arquivos pelo painel remove um caminho de escalada comum: o usuário editor comprometido não injeta mais código PHP no tema. ### Gere e troque os salts corretamente Use o gerador oficial do WordPress (api.WordPress.org/secret-key/1.1/salt) e substitua o bloco inteiro de 8 definições de uma vez. Nunca reaproveite chaves entre ambientes de teste e produção: uma chave vazada em staging permite forjar cookie em produção se forem iguais. Após a troca, todos os usuários precisam logar de novo, o que é esperado e desejável, porque expulsa qualquer sessão forjada que já existisse. ## Camada 2: Permissões de arquivo e o vetor do webshell Permissões de arquivo são a camada mais negligenciada e a que gera os incidentes mais graves no suporte da FULL. A regra base é 644 para arquivos e 755 para diretórios, com wp-config.php em 600. Permissão 777 em wp-content somada a upload sem validação de tipo resulta em webshell PHP executável direto pelo navegador, sem credencial nenhuma. O risco tende a aparecer em hospedagem compartilhada mal configurada, onde o instalador define 777 para "evitar erro de permissão": troca um erro de gravação por uma porta aberta permanente. O correto mantém o WordPress sem escrita nos próprios arquivos de código, liberando apenas uploads com validação de tipo MIME. Em VPS abaixo de 2 GB de RAM com WooCommerce, rode a checagem de permissões em lote pela madrugada, porque o scan recursivo em catálogos grandes gera pico de I/O no horário de pico. ## Camada 3: Hardening do login contra força bruta O login é onde a força bruta encontra o site, e aqui o hardening combina três medidas: limitar tentativas, exigir autenticação de dois fatores e ocultar a URL padrão `/wp-login.php`. A senha forte sozinha não basta: bots testam milhares de combinações por hora. Limitar a 5 tentativas por IP corta a maior parte desse tráfego. A camada de 2FA é a que mais muda o resultado, porque transforma uma credencial vazada em um acesso ainda bloqueado. Quem quer aprofundar a configuração encontra o passo a passo em como bloquear ataques de força bruta no login e em como ativar o 2FA no WordPress. O detalhe de campo que poucos guias trazem: ocultar a URL de login reduz o ruído de bots em até 90% nos logs, mas não é defesa real contra um ataque direcionado, então trate a ofuscação como redução de barulho, nunca como a trava principal. ## Camada 4: Hardening de plugins e a janela do CVE Plugins desatualizados são o maior vetor de invasão, e o hardening dessa camada é menos sobre escolher o plugin certo e mais sobre fechar a janela entre a divulgação do CVE e o patch. Segundo a Patchstack, 96% das vulnerabilidades de 2024 vieram de plugins. Plugin desatualizado com CVE conhecido e WAF ausente vira exploração automatizada em horas após a divulgação. A distinção que evita pânico: risco atual não é o mesmo que histórico. Pelo perfil público do WPVulnerability, o Contact Form 7 acumulou 12 CVEs, incluindo o crítico CVE-2020-35489 (CVSS 10.0, upload arbitrário antes da 5.3.2), todos corrigidos. O Elementor está em atenção, com o histórico CVE-2023-48777 (CVSS 9.9, upload sem restrição antes da 3.18.2). Muitos CVEs todos corrigidos é sinal de auditoria ativa, não de produto ruim. O que mata é a versão parada. ### Estabeleça uma rotina de atualização gerenciada Defina uma janela fixa de atualização e teste em staging antes de produção sempre que possível. A rotina ideal aplica patches de segurança em até 48 horas da divulgação e atualizações de funcionalidade em ciclo semanal. Ferramentas de gestão centralizada permitem aplicar o patch em vários sites de uma vez, o que reduz a janela de exposição de dias para horas, exatamente onde a exploração automatizada acontece. ## Camada 5: Firewall WAF e o que ele realmente cobre O firewall de aplicação (WAF) bloqueia o payload em tempo de execução e funciona como complemento das camadas de configuração, nunca como substituto. Um WAF como o do Wordfence ou do Cloudflare intercepta requisições maliciosas conhecidas (SQL injection, XSS, padrões de CVE) antes do PHP. Pelo perfil público do WPVulnerability, o próprio Wordfence acumulou 34 CVEs históricos, todos corrigidos: nenhuma ferramenta é imune. O papel de cada peça fica claro no ecossistema: o WAF compete por bloquear o payload em execução; a configuração endurecida compete por remover o vetor antes que exista payload; o patch compete por fechar o CVE antes da exploração. As três se sobrepõem de propósito: se o patch atrasa, o WAF segura; se o WAF tem bypass, a configuração limita o estrago. Para comparar opções de WAF, veja os 5 melhores plugins de segurança em 2026. ## Camada 6: Monitoramento, integridade e backup Monitoramento é a camada de hardening que assume que algo vai passar e prepara a resposta, porque nenhuma defesa é absoluta. Ela combina verificação de integridade de arquivos, alertas de mudança e backup testado. Na maioria dos sites que voltam ao suporte da FULL com reinfecção, o problema não foi a primeira limpeza: foi a ausência de monitoramento que deixou a persistência do invasor passar despercebida por semanas. O backup é o último recurso que torna o resto recuperável, mas só vale testado: um backup nunca restaurado é suposição, não garantia. A rotina recomendada mantém cópias diárias com retenção de 30 dias e teste de restauração mensal em ambiente isolado. Veja o passo a passo em como configurar backup automático no WordPress e o protocolo em o que fazer se o site for invadido. Atualizar o plugin fecha o CVE, mas não desfaz a permissão errada nem expulsa a sessão já aberta. ## Por que a autoridade da fonte importa neste tema Conteúdo de segurança genérico qualquer um escreve, mas catalogar uma vulnerabilidade exige autoridade reconhecida. A FULL é a única empresa brasileira que atua como CNA (CVE Numbering Authority) sob a CISA desde , autorizada a atribuir identificadores CVE oficiais. Quem escreve sobre vulnerabilidade aqui literalmente cataloga CVE no mesmo sistema global que o NVD consome. Isso muda o que você pode confiar de um guia de hardening. A diferença entre "instale este plugin" e "este CVE-2023-48777 permitia upload sem restrição até a versão 3.18.2" é a diferença entre opinião e dado verificável. O ecossistema melhorou: vulnerabilidades sem patch disponível caíram de uma fração relevante em para uma minoria em , à medida que a coordenação entre pesquisadores e CNAs amadureceu. Para auditar seu próprio site, ferramentas como WPScan e o repositório público de CVEs ajudam a cruzar a versão instalada com falhas conhecidas. --- ## Hardening gerenciado: Quando faz sentido terceirizar Fazer hardening manual camada por camada funciona, mas consome tempo recorrente, e para quem gerencia vários sites o hardening gerenciado costuma sair mais barato que o custo de uma invasão. O plano PRO da FULL custa R$849,90 e inclui 16 plugins premium de segurança e performance, entre eles o All in One Security para login e firewall, o Wordfence para scan e WAF, e o UpdraftPlus para backup. Dividido pelos 10 sites do plano, fica R$85 por site, com firewall, scanner, 2FA e backup já no bundle, sem licença avulsa de cada plugin. A conta que a gente vê no suporte da FULL é simples: uma limpeza de malware mais a perda de tráfego de um site na blacklist do Google custa muito mais que R$85 por site por ano. O hardening gerenciado não substitui entender as camadas, mas tira de você a tarefa repetitiva de aplicar patch em vários sites e revisar permissão a cada deploy. Conheça os detalhes em FULL.services/planos e a página do All in One Security incluso no bundle. Importante: a FULL entrega os plugins e a gestão, não a hospedagem, então o hardening gerenciado complementa o seu provedor atual em vez de substituí-lo. Para escanear o site agora e descobrir qual plugin está vulnerável, use o FULL Scan, gratuito e sem instalação, ou consulte o repositório de vulnerabilidades com dados oficiais de CVEs. O guia completo de cada etapa está em guia de segurança para WordPress e o aprofundamento técnico em como fazer o hardening de segurança passo a passo. ---

Perguntas frequentes sobre hardening no WordPress

O que é hardening no WordPress e por que ele difere de instalar um plugin de segurança?

Hardening é reduzir a superfície de ataque em camadas: servidor, wp-config.php, permissões, login e patches. Um plugin de segurança cobre só a camada de aplicação, com WAF e scan, e não corrige uma permissão 777 nem troca uma AUTH_KEY default. Por isso, na maioria das invasões vistas no suporte da FULL, a brecha estava numa camada de configuração que o plugin não enxerga. Hardening é disciplina recorrente, não um clique.

Por que um site com plugin de segurança instalado ainda pode ser invadido?

Porque o plugin atua na camada de aplicação, e a maioria das invasões entra por outra camada. Segundo a Patchstack, 96% das 7.966 vulnerabilidades de 2024 estavam em plugins de terceiros. Se o cookie de sessão é forjável por causa de uma AUTH_KEY default no wp-config.php, o invasor entra como admin sem nenhuma requisição suspeita, e o WAF não detecta anomalia. O hardening de configuração fecha esse vetor que o plugin sozinho não cobre.

Qual a diferença entre hardening de configuração e um firewall WAF?

O WAF bloqueia o payload em tempo de execução, interceptando requisições maliciosas conhecidas antes que cheguem ao PHP. O hardening de configuração remove o vetor antes que exista payload: troca chaves, corrige permissões e desativa edição de arquivos. As duas camadas se sobrepõem de propósito. Se o patch atrasa, o WAF segura; se o WAF tem um bypass, a configuração endurecida limita o estrago. Uma não substitui a outra.

É possível fazer hardening do WordPress sem quebrar plugins e o painel?

Sim, desde que você teste cada mudança em staging e respeite a ordem das camadas. Trocar os 8 SALTs apenas desloga usuários, sem quebrar nada; permissões 644/755 não afetam plugins legítimos; `DISALLOW_FILE_EDIT` só remove o editor de código do painel. O único cuidado real é com permissões abaixo de 644 em arquivos que o plugin precisa ler. Faça fora do horário de pico e mantenha um backup recente antes de cada ajuste.

Quanto tempo leva para um CVE de plugin ser explorado depois de divulgado?

Costuma levar horas, não dias. Um plugin desatualizado com CVE conhecido e sem WAF na frente é alvo de exploração automatizada logo após a divulgação pública, porque bots varrem a internet atrás dessa versão exata. Por isso a rotina de hardening recomenda aplicar patches de segurança em até 48 horas, idealmente em janela menor. Ferramentas de gestão centralizada aplicam o patch em vários sites de uma vez e reduzem a janela de exposição de dias para horas.

--- ## Próximos passos para endurecer seu WordPress hoje Comece o hardening pela camada de maior retorno: troque os SALTs do wp-config.php e ative o 2FA ainda hoje, porque juntas elas fecham os dois vetores mais explorados, forja de sessão e força bruta. Em seguida, audite as permissões de arquivo e estabeleça a rotina de patches em até 48 horas. Cada camada que você fecha reduz a superfície que o invasor tem para trabalhar, e nenhuma delas exige conhecimento avançado, apenas método. 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 quem está montando a defesa do zero. Hardening não termina: é uma revisão que volta a cada plugin novo, cada deploy e cada CVE divulgado.