Segurança WordPress: Guia Completo de Hardening

A segurança do WordPress não depende de nenhum truque secreto: ela é disciplina. A esmagadora maioria dos sites invadidos cai pelo básico mal feito — software desatualizado, senha fraca ou um plugin abandonado — e não por um ataque sofisticado. Fazer o hardening (o "endurecimento") do WordPress é justamente fechar essas portas óbvias antes que um bot as encontre.

Como o WordPress roda em mais de 40% de todos os sites da web (segundo o W3Techs), ele é o alvo mais procurado pelos ataques automatizados. A boa notícia é que a defesa também é conhecida e repetível. Antes dos comandos, vale enxergar a segurança como camadas — cada uma cobre a falha da anterior:

Por que o WordPress é o alvo preferido

Ser o software de sites mais popular do mundo tem um preço: cada vulnerabilidade descoberta vale muito para quem ataca, porque há milhões de alvos rodando o mesmo código. E como o código é aberto, qualquer pessoa pode estudá-lo em busca de falhas. Some a isso um universo enorme de usuários não técnicos, que instalam plugins sem critério e usam senhas fracas, e você tem o cenário perfeito para ataques em massa.

Na prática, a maioria das invasões chega por poucos caminhos previsíveis:

• Força bruta no login: bots tentam milhares de combinações de usuário e senha em wp-login.php e xmlrpc.php. Não é sofisticado — é automático e incessante.
• Plugins e temas desatualizados: de longe o vetor mais comum. Uma vulnerabilidade conhecida e já corrigida continua aberta em quem não atualizou, e existem exploits prontos para ela.
• Plugins de baixa qualidade: código mal escrito abre brechas de SQL injection ou XSS, permitindo roubar dados ou injetar scripts nas páginas.
• Core do WordPress antigo: rodar uma versão defasada do próprio WordPress mantém falhas já corrigidas expostas.

Repare que quase tudo se resolve com o feijão com arroz do hardening: atualizar, blindar o login e reduzir a superfície de ataque.

As camadas do hardening de WordPress

Hardening não é uma única mágica, e sim um conjunto de camadas com prioridades diferentes. Faça primeiro o que dá mais retorno por menos esforço. A tabela abaixo é a ordem que eu seguiria:

O restante do guia detalha essas medidas, agrupadas por camada.

Login e acesso: a porta mais atacada

O login é onde mais chegam tentativas de invasão, então é onde o esforço rende mais.

Não use o usuário "admin". Esse é o nome que todo ataque de força bruta presume, o que já entrega metade do trabalho. Crie um novo usuário com papel de administrador e um login não óbvio, transfira o conteúdo e apague o "admin" antigo. Aproveite para aplicar o princípio do menor privilégio: quem só escreve textos deve ser Autor ou Editor, nunca Administrador.

Senha forte de verdade. Use 16 caracteres ou mais, ou uma frase-senha longa, e guarde tudo num gerenciador de senhas (Bitwarden, 1Password). Nada de anotar em arquivo de texto. Para gerar algo aleatório rápido:

openssl rand -base64 20

Ative o 2FA no admin. Mesmo que a senha vaze, o segundo fator no celular barra o acesso. O Wordfence traz 2FA embutido; também dá para usar Google Authenticator ou Microsoft Authenticator com um plugin de autenticação. É a medida com melhor relação entre esforço e proteção depois de manter tudo atualizado.

Limite as tentativas de login. Bloquear o IP após algumas falhas quebra a força bruta automatizada. O Wordfence faz isso, assim como plugins dedicados como o Limit Login Attempts Reloaded.

Mascarar o wp-login.php ajuda, mas com ressalva. Trocar a URL de login (com o plugin WPS Hide Login, por exemplo) reduz o barulho dos bots que batem direto no endereço padrão. É segurança por obscuridade: corta ruído, mas não substitui limite de tentativas, senha forte e 2FA. Trate como um bônus, não como a defesa principal.

Atualizações e superfície de ataque

Se você fizer só uma coisa desta lista, que seja esta.

Ative as atualizações automáticas. No painel, o core já pode se atualizar sozinho; em Plugins e em Aparência > Temas, ligue o auto-update item a item, ou use um gerenciador central como o Easy Updates Manager. A ressalva de sempre: uma atualização pode, raramente, quebrar a compatibilidade com algum plugin — por isso o backup automático (mais adiante) vem antes de tudo.

Remova o que você não usa. Cada plugin e cada tema instalado é uma porta em potencial, mesmo desativado, porque o código continua no servidor e pode ser explorado. Desativar não basta: apague de fato os plugins e temas que não estão em uso. Menos código instalado é menos superfície de ataque. Se estiver revisando o que vale a pena manter, o guia de melhores plugins para WordPress ajuda a escolher com critério.

Arquivos e configuração do servidor

Aqui é o terreno de quem tem acesso ao servidor (via SSH, SFTP ou o gerenciador de arquivos da hospedagem).

Permissões de arquivo. A regra geral é diretórios em 755 e arquivos em 644. O wp-config.php, que guarda as credenciais do banco, merece uma permissão mais restrita — 640 ou até 600:

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
chmod 640 wp-config.php

Proteja o wp-config.php pelo servidor. Além da permissão, bloqueie o acesso direto ao arquivo. Em Apache (.htaccess, sintaxe 2.4):

<files wp-config.php>
  Require all denied
</files>

Desative a execução de PHP na pasta de uploads. Se alguém conseguir subir um arquivo .php malicioso, ele não deve ser executável. Coloque este .htaccess dentro de wp-content/uploads/ — nunca na raiz do site, ou você derrubaria o próprio WordPress:

# arquivo: wp-content/uploads/.htaccess
<FilesMatch "\.php$">
  Require all denied
</FilesMatch>

Impeça a edição de código pelo painel. Por padrão, um administrador consegue editar temas e plugins direto pelo dashboard — o que é um prato cheio para quem comprometer uma conta admin. Desligue isso no wp-config.php:

define('DISALLOW_FILE_EDIT', true);

Perímetro: WAF, HTTPS e headers

Estas camadas ficam entre o visitante e o WordPress, filtrando o que chega até ele.

Um WAF na frente do site. O Web Application Firewall filtra tráfego suspeito antes de ele tocar no WordPress. Há duas abordagens: o Wordfence roda como plugin dentro do WordPress; o Cloudflare e o Sucuri operam na nuvem, na frente do servidor, redirecionando o DNS. Se você ainda está entendendo o conceito, vale ler o que é um firewall e a comparação de firewall, antivírus e DNS seguro.

HTTPS em todo o site. Sem HTTPS, senhas e dados trafegam em texto puro e o navegador marca o site como "não seguro". O certificado SSL é gratuito (Let's Encrypt) e quase toda hospedagem já o oferece. O passo a passo está no guia de SSL e HTTPS no WordPress.

Headers HTTP de segurança. Eles instruem o navegador a se comportar de forma mais defensiva. Em Apache:

<IfModule mod_headers.c>
  Header always set X-Frame-Options "SAMEORIGIN"
  Header always set X-Content-Type-Options "nosniff"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  # HSTS: só ative depois que o HTTPS estiver 100% funcionando
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
  Header always unset X-Powered-By
</IfModule>

Duas observações que separam quem conhece o assunto: o antigo header X-XSS-Protection foi descontinuado pelos navegadores modernos — não vale mais a pena defini-lo. E a proteção real contra XSS hoje é a Content-Security-Policy, mas ela precisa ser calibrada para o seu site: um default-src 'self' copiado sem ajuste costuma quebrar temas, plugins e scripts de terceiros. Configure e teste com calma. Depois, use o securityheaders.com para conferir a nota.

Monitoramento e backup

Nenhuma defesa é perfeita, então você precisa saber quando algo dá errado — e conseguir voltar atrás.

Logs de segurança. Registrar logins (bem e mal sucedidos), instalação e remoção de plugins, mudanças de usuário e de configuração transforma um incidente silencioso em algo visível. O Wordfence já registra bastante coisa; o Simple History é uma opção gratuita e leve. Revise os logs periodicamente em busca de atividade estranha.

Backup off-site é inegociável. É a diferença entre um susto e um prejuízo. Guarde cópias automáticas fora do servidor do site (outra nuvem, outro provedor) e, o mais importante, teste a restauração de vez em quando — backup que nunca foi restaurado é só uma esperança. A lógica de manter cópias em lugares diferentes está no guia de backup 3-2-1 para empresas.

Wordfence, Sucuri ou Cloudflare: qual usar

Não existe escolha única certa; depende do site e do orçamento. Um resumo honesto das três opções mais comuns:

Na prática, muita gente combina: Cloudflare ou Wordfence gratuito para a maioria dos sites e o Sucuri quando a criticidade justifica um WAF gerenciado. Para o quadro maior de proteção de um negócio, veja o guia de cibersegurança para PMEs.

A própria documentação oficial do WordPress mantém um guia de referência sobre hardening do WordPress que vale como leitura de apoio.

Perguntas frequentes sobre segurança no WordPress

O Wordfence gratuito é suficiente?

Para a maioria dos sites pequenos e médios, sim. A versão gratuita já traz firewall a nível de aplicação, verificação de malware, 2FA e limite de tentativas de login. A versão paga adiciona regras de firewall atualizadas em tempo real e verificação em nuvem. Comece no gratuito e avalie o upgrade conforme a criticidade do site.

Dá para usar WordPress sem plugin de segurança?

Dá, mas não é recomendado se você não domina servidor. Todo site WordPress exposto recebe tentativas automáticas de login e varreduras o tempo todo. Sem uma camada de proteção — seja um plugin como o Wordfence, seja um WAF na frente do site como o Cloudflare — você fica dependente só de senha forte e de manter tudo atualizado.

Atualização automática pode quebrar o site?

Pode, embora seja incomum, quando um plugin não é compatível com a nova versão. Por isso a regra é sempre ter backup automático antes de atualizar. A grande maioria das atualizações são correções de segurança, e o risco de ficar desatualizado é muito maior do que o de uma atualização quebrar algo.

Fui invadido. Como limpo o site?

Coloque o site em manutenção, restaure a partir de um backup limpo anterior à invasão, troque todas as senhas (admin, FTP/SSH e banco de dados), atualize tudo, aplique o hardening e rode uma verificação de malware. Se não tiver backup, serviços como o do Sucuri fazem a remoção do malware.

Como sei se o WordPress foi invadido?

Sinais comuns: site lento sem motivo, redirecionamentos ou pop-ups estranhos para os visitantes, alertas de malware do plugin de segurança, o Google marcando o site como perigoso na busca e logins ou arquivos que você não reconhece. Um plugin de log (como o Simple History) e o verificador do Wordfence ajudam a flagrar isso cedo.

Conclusão

Segurança no WordPress é disciplina, não sorte: atualizar tudo, blindar o login com senha forte e 2FA, reduzir a superfície de ataque, colocar um WAF na frente e manter backup off-site testado. Nenhuma dessas camadas é infalível sozinha, mas juntas elas colocam o seu site muito à frente da maioria — que segue exposta justamente por não fazer o básico.

Comece pelo que rende mais: ative as atualizações automáticas, troque a senha e ligue o 2FA hoje. O resto do hardening vem em cima dessa base.

Leia também: o que é WordPress, SSL e HTTPS no WordPress e backup 3-2-1 para empresas.