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.

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 maio de 2022, 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 2023 para uma minoria em 2026, à 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

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.