Segurança WordPress em 2026: Uma Lista de Verificação de Reforço para Sites de Missão Crítica

A segurança no WordPress não é uma caixa de verificação. É um sistema em camadas que tem de resistir a bots, atacantes oportunistas e eventuais tentativas dirigidas — e o custo de falhar aumentou. Um site corporativo comprometido em 2026 significa exposição ao RGPD, perda de confiança, semanas de limpeza forense e danos de SEO que podem demorar meses a recuperar.

Esta é a lista de verificação que aplico em cada auditoria que realizo. Não é uma lista genérica do tipo “instala o Wordfence e está feito” — são os controlos em camadas que realmente importam em sites WordPress e WooCommerce de missão crítica.

1. Camada de servidor e alojamento

O endurecimento mais robusto do WordPress não serve de nada se o servidor por baixo for partilhado com centenas de outros sites e o fornecedor não os isolar corretamente. Comece aqui.

Versão e isolamento de PHP

Execute uma versão de PHP suportada (8.2 ou 8.3 em 2026). Cada versão em atraso significa correções de segurança em falta e pior desempenho. Se o seu fornecedor ainda servir PHP 7.4 em 2026, está a pagar por negligência.

Para sites corporativos, insista em pools PHP-FPM isolados por site, e não num pool partilhado. Isto impede que um vizinho comprometido consiga aceder ao seu código ou à ligação à base de dados.

Firewall de Aplicação Web

Uma WAF à frente do WordPress filtra o ruído — abuso de XML-RPC, tentativas de força bruta, assinaturas de exploits comuns — antes de os pedidos chegarem ao PHP. A WAF gratuita da Cloudflare com limitação de taxa trata 90% do volume; para sites de maior risco, o plano Pro adiciona gestão de bots e regras geridas otimizadas para WordPress.

As firewalls baseadas em plugins (Wordfence, Solid Security) situam-se dentro do PHP, o que significa que só atuam depois de o PHP já ter carregado. Têm o seu lugar — regras ao nível da aplicação, monitorização de inícios de sessão — mas não substituem uma WAF de perímetro.

HTTPS e cabeçalhos

TLS 1.2 no mínimo, idealmente 1.3. Cabeçalho HSTS com um max-age de pelo menos 1 ano assim que tiver a certeza de que o certificado é estável. Os outros cabeçalhos que devem estar em todas as respostas de um site WordPress sério:

• X-Content-Type-Options: nosniff
• X-Frame-Options: SAMEORIGIN (ou uma CSP adequada com frame-ancestors)
• Referrer-Policy: strict-origin-when-cross-origin
• Permissions-Policy restrita às APIs que o site efetivamente utiliza
• Content-Security-Policy — a mais difícil de configurar corretamente, mas a de maior impacto

2. Core do WordPress

O core é a parte mais fácil — mas é também onde a maioria das histórias de “fomos hackeados” realmente começa. Quase sempre devido a atualizações adiadas ou a uma constante mal configurada.

Atualizações automáticas para versões menores e de segurança

Em wp-config.php, defina define( 'WP_AUTO_UPDATE_CORE', 'minor' );. Isto aplica patches de segurança automaticamente sem arriscar alterações disruptivas de uma versão principal. As atualizações de versão principal permanecem manuais e testadas em ambiente de staging.

Desativar a edição de ficheiros a partir do painel de administração

Esta linha em wp-config.php bloqueia o vetor de pós-comprometimento mais comum — o envio de código malicioso através de Aparência → Editor de Ficheiros do Tema:

define( 'DISALLOW_FILE_EDIT', true );

Combine com DISALLOW_FILE_MODS se não precisar de instalar plugins/temas através do painel de administração — as alterações ao código são feitas via Git de qualquer forma.

Salts e prefixo da base de dados

Renove as oito chaves de autenticação e salts em wp-config.php pelo menos uma vez por ano e imediatamente após qualquer suspeita de comprometimento. Utilize o gerador oficial do WordPress.org. Um prefixo de base de dados personalizado (em vez de wp_) constitui um pequeno obstáculo a tentativas automatizadas de injeção SQL — defina-o no momento da instalação; alterá-lo num site em produção traz mais riscos do que benefícios.

3. Plugins e temas

É aqui que reside a verdadeira superfície de ataque. Cada plugin é código executado com acesso total ao sistema de ficheiros e à base de dados. Um plugin abandonado de um fornecedor que desapareceu há dois anos é um exploit à espera de acontecer.

Auditar e reduzir

Uma vez por trimestre: liste todos os plugins instalados e faça três perguntas por plugin.

• Este plugin ainda está a ser utilizado? (Analise a utilização real das funcionalidades, não o “pode ser útil um dia”.)
• Foi atualizado nos últimos 12 meses pelo fornecedor?
• Dispõe de uma política de divulgação de segurança publicada?

Se a resposta a alguma destas perguntas for não, o plugin é substituído ou removido. A proliferação de plugins é o maior preditor de comprometimento de um site WordPress — mais do que a versão do core, mais do que o alojamento.

Evitar plugins nulled / pirateados

Não deveria ser necessário dizer isto em 2026, mas continuo a encontrá-los em auditorias. Os plugins premium nulled vêm quase sempre acompanhados de backdoors. Os €99 que “poupa” num ano de WPML ou numa extensão premium do WooCommerce transformam-se numa fatura de resposta a incidentes na casa dos cinco dígitos.

Restringir XML-RPC e REST API

O XML-RPC é uma interface legada ainda ativada por omissão. A menos que esteja a utilizar o Jetpack ou um cliente de publicação remota, desative-o completamente ao nível do servidor (um único bloco de localização nginx ou uma regra no ficheiro .htaccess).

A REST API é mais útil, mas a exposição predefinida de /wp-json/wp/v2/users vaza nomes de utilizador para pedidos anónimos. Restrinja esse endpoint a pedidos autenticados com um pequeno filtro rest_authentication_errors.

4. Login e acesso

A maioria das violações começa no formulário de login. Reforçá-lo não é opcional.

Autenticação de dois fatores em todas as contas de administrador

2FA baseado em TOTP (via Wordfence Login Security, Two Factor ou um fornecedor SSO) em todas as contas com o papel de administrator ou editor. Sem exceções, incluindo a sua. Se subcontratar o desenvolvimento, o seu colaborador terá a sua própria conta com 2FA, não um login de administrador partilhado.

Renomear ou limitar a taxa de pedidos em /wp-login.php

A segurança por obscuridade é fraca, mas combinada com a limitação de taxa reduz significativamente o tráfego de bots. Mova o wp-login.php para um caminho personalizado (o WPS Hide Login faz isso de forma limpa), ou aplique um limite de taxa estrito ao nível do WAF — 5 tentativas por 15 minutos por IP é razoável.

Política de palavras-passe fortes aplicada

O medidor de robustez integrado do WordPress é sugestivo, não vinculativo. Utilize um plugin (Password Policy Manager, ou integrado na sua suite de segurança) que bloqueie palavras-passe fracas. Mínimo de 12 caracteres, deve incluir as quatro classes de caracteres, rejeitado contra uma lista de palavras-passe conhecidas como comprometidas.

5. Sistema de ficheiros e permissões

Uma instalação WordPress com permissões corretas limita o impacto de qualquer comprometimento.

• Diretórios: 755
• Ficheiros: 644
• wp-config.php: 600 (legível apenas pelo utilizador com que o servidor web é executado)
• Proprietário: o utilizador de deploy, não o utilizador do servidor web
• Utilizador do servidor web: apenas leitura em tudo o que esteja fora de wp-content/uploads/ e das poucas caches que necessitam de acesso de escrita

Desative a execução de PHP dentro de wp-content/uploads/ ao nível do servidor. Este é o controlo defensivo mais útil contra o padrão de ataque “carregaram um .php disfarçado de .jpg”.

6. Base de dados

A base de dados raramente é o ponto de entrada, mas é quase sempre onde os danos são causados — exfiltração de dados, injeção de utilizador administrador, conteúdo de publicações malicioso.

• Utilizador de base de dados dedicado por site com os privilégios mínimos necessários (sem GRANT, sem DROP DATABASE)
• Base de dados e servidor web em rede privada; sem porta de base de dados pública
• Cópias de segurança encriptadas armazenadas fora do servidor, retidas durante pelo menos 30 dias
• Restauro testado pelo menos duas vezes por ano — uma cópia de segurança que nunca restaurou é uma esperança, não uma cópia de segurança

7. Monitorização e resposta

Acabará por ser comprometido. A diferença entre um incidente de 24 horas e um desastre de 6 semanas está em saber se fica a par pela sua monitorização ou por um cliente.

Monitorização da integridade de ficheiros

Uma análise diária que compara o sistema de ficheiros atual com uma linha de base conhecida e válida. Qualquer ficheiro de núcleo modificado, qualquer novo ficheiro PHP em wp-content/uploads/, qualquer alteração ao .htaccess gera um alerta. O Wordfence faz isto; tal como ferramentas empresariais como o OSSEC.

Monitorização de disponibilidade e comportamento

As verificações simples de disponibilidade (UptimeRobot, BetterUptime) detetam o óbvio. Mais útil: a deteção de anomalias no tempo de resposta — um site que abranda subitamente 3× tem frequentemente um cryptominer em wp-content/uploads/.

Plano de resposta documentado

Escrito antes de ser necessário: quem contacta quem, o que é colocado offline, onde está a cópia de segurança limpa mais recente, como é o fluxo de notificação ao abrigo do RGPD caso dados pessoais tenham sido expostos. Um documento de 1 página supera um plano perfeitamente arquitetado que nunca irá ler em pânico.

Como isto se parece na prática

A lista de verificação completa tem mais de 30 controlos. A maioria dos sites que audito tem entre 5 a 10 deles implementados — os mais económicos, mais aquilo de que o programador original se lembrou. Os restantes 20 são onde está a verdadeira redução de risco.

A boa notícia: não precisa de um projeto de segurança de seis meses para atingir um estado defensável. A primeira metade desta lista — endurecimento do servidor, constantes de núcleo, auditoria de plugins, 2FA, permissões de ficheiros — fica concluída em dois ou três dias focados. O resto é uma cadência trimestral.

Se preferir não ser você a percorrer tudo isto, é exatamente isso que a Auditoria de Engenharia WordPress cobre — a mesma revisão de segurança entregue como um plano de remediação priorizado.