🔒 Segurança do WordPress em 2026: um guia completo para proteção de sites

Um site WordPress é pirateado não porque o motor está «cheio de buracos». É pirateado porque o proprietário adiou a atualização de um plugin, definiu a palavra-passe admin123 e deixou o xmlrpc.php aberto. Bots automatizados varrem a internet continuamente.

Não lhes interessa se vende velas artesanais ou gere uma loja online. Eles vão encontrar e explorar a vulnerabilidade. Força bruta de login, injeção SQL, upload de shell através de um plugin vulnerável, tudo isto funciona 24 horas por dia.

A boa notícia: pode construir uma proteção básica numa noite, sem conhecimentos técnicos profundos. Abaixo está um conjunto comprovado de medidas, desde a instalação de uma firewall até ao reforço manual do servidor. Aplicamos tudo o que aqui é descrito nos nossos próprios projetos.

💡 Visão geral rápida:

• Instale uma firewall: BBQ ou Wordfence, a primeira linha de defesa bloqueia a maioria dos ataques antes mesmo de chegarem ao WordPress.
• Feche os pontos de entrada típicos: xmlrpc.php, API REST para utilizadores não autenticados, listagem de diretórios, o editor de ficheiros no painel de administração.
• Configure atualizações automáticas para o core, temas e plugins. Uma versão desatualizada de um plugin é o principal vetor de ataque.
• Faça um backup que seja guardado FORA do servidor. Sem um backup, a recuperação após uma pirataria significa reinstalar o WordPress do zero.
• Ative a autenticação de dois fatores para todos os administradores. Uma palavra-passe pode ser adivinhada; um segundo fator não.

Onde atacam primeiro: vetores de ataque típicos

A maioria das pessoas imagina um hacker como alguém num terminal, a adivinhar manualmente a palavra-passe de administrador. A realidade é mais prosaica: praticamente todos os ataques são realizados por bots que seguem um script. Procuram vulnerabilidades conhecidas em plugins e temas, batem no xmlrpc.php, vasculham /wp-content/uploads/ à procura de ficheiros PHP executáveis.

Os principais vetores de ataque contra o WordPress:

• Plugins e temas desatualizados. De acordo com os relatórios da Sucuri, cerca de 40% dos sites pirateados estavam a usar uma versão desatualizada do CMS, de um plugin ou de um tema no momento da infeção. Os programadores fecham as brechas com patches, mas apenas se aplicar esses patches.

• Palavras-passe fracas. Os ataques de força bruta tentam dezenas de milhares de combinações por minuto. Uma palavra-passe de 6 caracteres sem caracteres especiais é decifrada instantaneamente.

• Alojamento inseguro. O alojamento partilhado barato poupa no isolamento de contas: se um site vizinho no servidor for pirateado, o ataque pode alastrar para o seu.

• Permissões de escrita excessivas. Quando o servidor web pode escrever em qualquer ficheiro, uma shell carregada através de uma brecha ganha controlo total sobre o site.

Compreender estes vetores é metade da defesa. A outra metade é a ação concreta.

Nível 1: proteção rápida que pode configurar em meia hora

É por aqui que deve começar hoje. Cada ação demora minutos, não requer edição de código e não vai partir o seu site.

Instalar uma firewall: BBQ Firewall

O BBQ Firewall é um plugin de Jeff Starr que funciona com o princípio de «instalar e esquecer». Sem definições, sem interferência com o .htaccess ou a base de dados. Simplesmente bloqueia pedidos de URL maliciosos antes de chegarem ao WordPress: eval(), base64_decode, strings excessivamente longas, tentativas de injeção.

O plugin pesa menos de 10 KB e não cria carga. Ao mesmo tempo, deteta injeção SQL, XSS, uploads de ficheiros executáveis e ataques via referrers «maliciosos».

Na prática, o BBQ é frequentemente instalado POR CIMA do Wordfence ou do Solid Security; resolvem problemas diferentes e não entram em conflito. Uma firewall ao nível do pedido mais um plugin de segurança completo proporcionam uma defesa em camadas.

Ativar a autenticação de dois fatores

Uma palavra-passe pode ser adivinhada, intercetada ou comprada num despejo de bases de dados violadas. Um segundo fator, um código único de uma aplicação autenticadora, quebra toda a matemática dos ataques de força bruta.

O WordPress não tem 2FA integrado. O caminho mais fácil é instalar o Solid Security (anteriormente iThemes Security) ou o Wordfence. Ambos incluem 2FA na versão gratuita. Após a ativação, vá a Segurança → Definições → Autenticação de Dois Fatores e ative-a para o perfil de Administrador.

Estes mesmos plugins fecham mais uma dúzia de vulnerabilidades de raiz:

• Solid Security: altera o URL de login (/wp-admin → o seu slug único), define um limite de tentativas de login, analisa ficheiros em busca de alterações, bloqueia IPs após uma série de logins falhados, verifica plugins e temas em busca de vulnerabilidades conhecidas.

• Wordfence: Web Application Firewall com regras atualizadas automaticamente, scanner de malware, proteção contra força bruta, monitorização de tráfego em tempo real. É especialmente bom para limpar um site já pirateado: encontra backdoors, ficheiros do core modificados, spam oculto.

Só precisa de UM deles. Nos nossos projetos, instalamos o Wordfence + BBQ: o primeiro fornece uma WAF e um scanner, o segundo corta os pedidos de lixo antes mesmo de se aproximarem.

Desativar o xmlrpc.php

O XML-RPC é uma interface para trabalho remoto com o WordPress através de aplicações móveis e trackbacks. Hoje, a grande maioria dos sites não precisa dele, mas continua a ser um dos pontos mais atacados: os bots usam o xmlrpc.php para fazer força bruta de palavras-passe e conduzir ataques DDoS.

Pode desativá-lo de duas formas. A forma rápida, através de um plugin: o Solid Security fá-lo com um clique. A forma adequada, ao nível do servidor, no .htaccess:

1
<Files xmlrpc.php>
2
Order Deny,Allow
3
Deny from all
4
</Files>

Adicione este bloco ao .htaccess raiz e esqueça o xmlrpc. Se usar a aplicação móvel do WordPress ou serviços externos que precisam de XML-RPC, verifique primeiro se funcionam sem ele. Em 2026, as alternativas, a API REST com autenticação, cobrem quase todos os cenários.

Desativar a listagem de diretórios

Abra o вашсайт.com/wp-content/uploads/ no seu navegador. Se vir uma lista de ficheiros, tem um problema. A listagem de diretórios mostra a estrutura do seu site a qualquer pessoa que se dê ao trabalho de olhar.

A solução: uma linha no .htaccess:

1
Options -Indexes

Adicione também um index.php vazio a todos os diretórios suspeitos: /wp-content/uploads/, temas, plugins que não tenham o seu próprio index.php.

Desative o editor de ficheiros no painel de administração

O WordPress inclui a funcionalidade de editar ficheiros .php de temas e plugins diretamente no painel de administração: Aparência → Editor de Ficheiros do Tema e Plugins → Editor de Ficheiros do Plugin. É conveniente, até que alguém não autorizado aceda ao painel de administração. Nesse momento, torna-se uma ferramenta pronta a usar para carregar uma shell.

Adicione uma constante ao wp-config.php:

1
define('DISALLOW_FILE_EDIT', true);

É tudo. O editor desaparece do painel de administração. Utilize FTP/SFTP para editar ficheiros, menos conveniente, mas mais seguro.

Nível 2: proteção manual do WordPress

As medidas seguintes vão um pouco mais fundo: exigem a edição de ficheiros de configuração e a compreensão da estrutura do servidor. O resultado é um site que os bots ignoram porque não veem WordPress nele.

Atualizar os sais de segurança

Sais, chaves de segurança e sais, oito linhas no wp-config.php que encriptam os cookies de autenticação. Alterá-los termina instantaneamente a sessão de todos, incluindo a de um potencial atacante com uma sessão roubada.

Vá a api.wordpress.org/secret-key/1.1/salt/, copie o bloco gerado e substitua a secção correspondente no wp-config.php por ele. Demora um minuto. Faça isto sempre que suspeitar de um comprometimento.

Alterar o prefixo das tabelas da base de dados

Por predefinição, todas as tabelas do WordPress têm os nomes wp_posts, wp_users e wp_options. As injeções de SQL são muitas vezes adaptadas especificamente ao prefixo padrão.

Numa instalação nova, especifique um prefixo não padrão no wp-config.php:

1
$table_prefix = 'wp83x_';

Para um site existente, alterá-lo é mais difícil: precisa de renomear as tabelas na base de dados e atualizar os valores em usermeta e options. Não tente isto sem ter bons conhecimentos de phpMyAdmin e SQL, o risco de deitar o site abaixo é demasiado alto.

Mover o wp-config.php para acima da raiz web

O wp-config.php contém a palavra-passe da base de dados e as chaves de encriptação. Se o servidor web o servir acidentalmente como texto simples, o que acontece durante uma atualização do PHP mal sucedida, o atacante obtém tudo.

Solução: mova o wp-config.php um nível acima do diretório raiz do site, por exemplo de /public_html/ para a pasta inicial do alojamento. O WordPress procura automaticamente a configuração no diretório pai, o código não se vai quebrar.

Ocultar a versão do WordPress

O gerador <meta name="generator" content="WordPress X.X.X"> no código fonte da página é uma prenda para os bots. Eles cruzam a versão com uma base de dados de vulnerabilidades conhecidas e atacam com precisão.

Remova o gerador através do functions.php:

1
// Remove the WordPress generator meta tag from the page source code
2
function no_generator() {
3
    return '';
4
}
5
add_filter('the_generator', 'no_generator');

A função no_generator() devolve uma string vazia em vez da saída padrão da versão. O filtro the_generator interceta a saída da meta tag e todas as suas variações, para feeds, RSS e a API REST.

Apague também o readme.html e o liesmich.html da raiz da instalação, eles também expõem a versão. Após uma atualização do WordPress, estes ficheiros podem reaparecer, verifique uma vez por mês.

Configurar cabeçalhos de segurança HTTP

Os cabeçalhos de resposta HTTP dizem ao navegador como lidar com o conteúdo. Cabeçalhos de segurança configurados corretamente bloqueiam clickjacking, XSS e falsificação de conteúdo.

Um conjunto mínimo para o WordPress, adicione estas linhas ao .htaccess:

1
Header set X-Frame-Options "SAMEORIGIN"
2
Header set X-Content-Type-Options "nosniff"
3
Header set Referrer-Policy "strict-origin-when-cross-origin"
4
Header set X-XSS-Protection "1; mode=block"

O plugin HTTP Headers permite-lhe fazer o mesmo através do painel de administração, se preferir não mexer na configuração do servidor.

Para uma configuração avançada, use a Política de Segurança de Conteúdo (CSP). Mas atenção: uma CSP incorreta quebra o painel de administração, o carregamento de tipos de letra e a funcionalidade dos plugins. Implemente-a gradualmente, começando com o modo Content-Security-Policy-Report-Only.

Restringir as permissões dos ficheiros

Permissões, a última linha de defesa. Se um atacante enviar um ficheiro, mas não o conseguir executar, o ataque é travado.

Regras básicas:

• Diretórios: 755, o proprietário lê, escreve e executa; o grupo e outros leem e executam.
• Ficheiros: 644, o proprietário lê e escreve, os outros apenas leem.
• wp-config.php: 400, apenas o proprietário lê.
• .htaccess: 444, apenas de leitura para todos, se o WordPress não o editar automaticamente.

Evite absolutamente o 777. Sim, alguns plugins pedem 777 no wp-content/uploads/. Não o conceda. 755 na pasta e 644 nos ficheiros lá dentro é suficiente para os uploads de media.

O que fazer se o site já estiver pirateado

Uma pirataria é descoberta de várias formas: um redirecionamento para um casino, envio de spam, um aviso «Este site pode estar pirateado» nos resultados de pesquisa do Google, uma queixa do alojador. A sequência de ações:

• Alterar imediatamente todas as palavras-passe: administrador do WordPress, FTP/SFTP, base de dados, painel de controlo do alojamento. Comece por esta última. Se o pirata estiver no painel de alojamento, ele simplesmente criará um novo administrador.

• Restaurar o site a partir de um backup feito ANTES da pirataria. Um backup recente feito após o comprometimento contém muito provavelmente uma backdoor. Se não houver backup, passe ao próximo passo.

• Instalar o Wordfence e executar uma verificação completa. O plugin encontrará ficheiros principais modificados, código suspeito, backdoors ocultas. Apague tudo o que o scanner sinalizar e, em seguida, substitua o núcleo do WordPress por uma cópia nova: o botão «Reinstalar» em Painel → Atualizações.

• *Verificar wp-content/uploads/ à procura de ficheiros .php.* Eles não pertencem a esse local. Qualquer .php na pasta de uploads é quase de certeza uma shell.

Veja o vídeo acima, ele analisa os erros típicos de segurança do WordPress e como corrigi-los, desde palavras-passe fracas a permissões de ficheiros incorretas.

• Ligue monitorização externa. Sucuri, um serviço na cloud com uma WAF e uma equipa de resposta. A WAF filtra o tráfego antes de este chegar ao servidor. Se ocorrer uma violação, a equipa da Sucuri limpa o site em horas. O preço começa nos $199/ano para o plano básico com limpeza e monitorização. Não é gratuito, mas quando um site gera receita, o tempo de inatividade custa mais.

Certifique-se de que regista o seu site no Google Search Console. Se o Google detetar código malicioso, receberá uma notificação antes de o site desaparecer dos resultados de pesquisa.

Proteção contra ransomware: porque é que as cópias de segurança resolvem tudo

O ransomware encripta os ficheiros do site e exige um resgate. Os sites WordPress são um alvo frequente: encomendas, bases de dados de clientes, conteúdo. Perder tudo de um dia para o outro é um cenário real sem uma cópia de segurança.

Três regras:

• Cópia de segurança fora do servidor. Cloud ou um FTP separado. UpdraftPlus e Duplicator automatizam a descarga.
• Firewall e scanner. Wordfence + BBQ bloqueiam uploads de ficheiros maliciosos na fase do pedido.
• Apenas fontes oficiais. O diretório WordPress.org e sites de programadores com reputação. Nada de temas «gratuitos» de torrents.

Monitorização automática da integridade dos ficheiros

Proteção do lado do servidor, não uma ação pontual. Junte as verificações num script de shell em cron, uma vez por dia, resultados para o email:

1
SITE_ROOT="/absolute/path/to/public_html"
2
 
3
find "$SITE_ROOT" -mtime -1 -name "*.php" \
4
    -printf '%TY-%Tm-%Td %TT\t%p\n' >> /tmp/file-changes.log
5
 
6
find "$SITE_ROOT" -mtime -7 -name "*.php" \
7
    | xargs grep -l -i "eval\|base64_decode\|iframe\|file_get_contents" \
8
    >> /tmp/suspicious-code.log
9
 
10
find "$SITE_ROOT/wp-content/uploads" -name "*.php" -print \
11
    >> /tmp/php-in-uploads.log
12
 
13
find /home -type d -perm 0777 >> /tmp/perms.log
14
find /home -type f -perm 0777 >> /tmp/perms.log
15
 
16
mailx -s "Webserver File Audit $(date +%F)" admin@example.com \
17
    < /tmp/suspicious-code.log

O script é executado uma vez por dia via cron. O primeiro bloco find -mtime -1 mostra os ficheiros PHP alterados nas últimas 24 horas, o principal detetor de intrusões. O segundo procura assinaturas de shell: eval, base64_decode, iframes ocultos. O terceiro deteta PHP na pasta de uploads, onde PHP legítimo nunca deve estar. O quarto encontra ficheiros e pastas com permissões 777. O resultado é enviado para o email. A monitorização proativa deteta uma intrusão numa fase inicial, antes de o Google se aperceber e banir o site dos resultados de pesquisa.

Sucuri: uma firewall na cloud para quando não tem tempo para configurações

Como funciona: o tráfego passa pelo proxy na cloud da Sucuri com uma WAF, os pedidos maliciosos são bloqueados antes de chegarem ao alojamento. O site carrega mais rápido graças à CDN. Capacidades principais: uma WAF com assinaturas em tempo real, proteção DDoS, limpeza automática de malware.

Os planos começam nos $199/ano. Não existe versão gratuita, mas o plugin de scanner da Sucuri verifica alterações nos ficheiros sem a WAF. Para um site comercial, é um investimento justificado. Para um blogue pessoal, Wordfence + BBQ é suficiente.

⁉️🤔 Perguntas frequentes

O WordPress em si é seguro?

O núcleo do WordPress é revisto por centenas de programadores e auditores de segurança. O problema não é o núcleo; o problema são plugins desatualizados, temas de fontes não confiáveis e palavras-passe como 123456. Atualizações regulares e uma firewall básica oferecem proteção suficiente para a maioria dos sites.

Posso funcionar sem plugins de segurança?

Pode, se estiver disposto a configurar manualmente uma firewall ao nível do servidor: iptables, mod_security, firewall 7G/8G no .htaccess, acompanhar os CVE de cada plugin e escrever scripts cron para monitorização. Para todos os outros, instalar o Wordfence ou o Solid Security é uma hora contra dezenas de horas de trabalho manual.

As atualizações são necessárias se houver uma firewall instalada?

Sim, absolutamente. Uma firewall bloqueia ataques externos, mas se estiver instalado um plugin com uma vulnerabilidade conhecida, mais cedo ou mais tarde será encontrado um vetor que a firewall não deteta. Atualizar todos os componentes do WordPress é a base sem a qual as outras medidas funcionam a meio gás.

Que plugin de segurança devo escolher?

Para proteção mínima: BBQ Firewall, bloqueia pedidos de URL maliciosos, configuração zero. Para proteção total: Wordfence, WAF, scanner, 2FA, proteção contra força bruta, tudo na versão gratuita. A combinação BBQ + Wordfence cobre ambas as camadas sem conflitos.

E quanto à REST API, devo desativá-la?

A REST API é necessária ao WordPress para o editor de blocos Gutenberg, vários plugins e integrações externas. Desativá-la completamente irá quebrar o painel de administração. Em vez disso, restrinja o acesso: deixe apenas os endpoints públicos para utilizadores não autenticados. O plugin REST API Toolbox permite-lhe configurar o acesso de forma flexível sem intervenção cirúrgica.

Com que frequência devo analisar o site em busca de vírus?

Automaticamente, diariamente através de scripts cron: verificação de ficheiros alterados, procura de .php na pasta de uploads. Manualmente, uma vez por mês: entre no Wordfence, execute uma análise completa, verifique a lista de plugins em busca de abandonados. Sem atualizações há mais de um ano, elimine ou substitua.

Posso perder posições no Google por causa de um ataque?

Pode, e rapidamente. O Google analisa os sites em busca de código malicioso e sinaliza os infetados com um aviso nos resultados de pesquisa. Se o ataque não for corrigido em poucas semanas, o site é desindexado. Registe o seu site no Google Search Console e receberá uma notificação sobre o problema assim que for detetado.

Mudar de alojamento ajuda a prevenir ataques?

Parcialmente. Um alojamento de qualidade acrescenta as suas próprias camadas: isolamento de contas, monitorização de rede, atualização automática do PHP. Mas o alojamento não protege contra um plugin com falhas que instalou ou a palavra-passe qwerty. A segurança é um bolo de camadas: alojamento, atualizações, firewall, direitos de acesso e backups.

Segurança do WordPress: por onde começar hoje

A regra principal da segurança do WordPress é não tentar resolver tudo de uma vez. Comece com três passos:

• Se não houver firewall, instale o BBQ Firewall. Um minuto.
• Se não houver backups externos ao servidor, configure o UpdraftPlus com envio para a nuvem. Dez minutos.
• Se o 2FA não estiver ativo para os administradores, ative-o através do Wordfence. Cinco minutos.

Depois volte à lista acima: desative o xmlrpc, atualize os sais, desative o editor de ficheiros, configure os cabeçalhos de segurança. Um item por dia e, numa semana, o seu site estará uma ordem de grandeza mais protegido do que estava ontem.

Que medidas de segurança já estão a funcionar no seu site? Conte-me nos comentários, estou curioso para comparar abordagens.