Segurança WordPress: checklist para empresas da UE (2026)

Esta checklist de segurança WordPress reúne as 25 medidas que recomendamos para qualquer site empresarial na UE, organizadas em seis áreas: alojamento, software WordPress, contas, monitorização, cópias de segurança e documentação. A ordem conta: os três primeiros grupos travam a maior parte dos ataques; os três últimos permitem detetar um incidente, recuperar o site e demonstrar o que foi feito.

Cada ponto traz uma justificação curta e, quando faz sentido, uma ligação para um guia mais completo. Nenhuma checklist torna um site «100 % seguro», mas esta garante um nível de proteção que se consegue explicar a um cliente, a um auditor ou à autoridade de controlo.

Porque é que a rapidez conta: a empresa de segurança Patchstack contabilizou 11 334 novas vulnerabilidades no ecossistema WordPress em 2025, 91 % delas em plugins, e concluiu que cerca de metade das mais graves foi explorada nas primeiras 24 horas (Patchstack, State of WordPress Security in 2026, relatório de um fornecedor do setor). Uma rotina vale mais do que qualquer ferramenta isolada.

Alojamento e servidor

Se o servidor for frágil, nenhuma configuração dentro do WordPress compensa totalmente essa falha.

• HTTPS em todas as páginas e, depois, HSTS. O HTTPS cifra inícios de sessão, formulários e encomendas durante a transmissão, e o art. 32.º, n.º 1, alínea a), do RGPD menciona expressamente a cifragem. O HSTS (RFC 6797) só deve ser ativado quando o HTTPS já funcionar em todo o site, começando com um max-age curto: durante esse período, os browsers recusam ligações HTTP simples.
• Uma versão de PHP suportada. Os ramos de PHP em fim de vida deixam de receber correções de segurança; convém comparar a versão em uso com a lista oficial.
• SFTP ou SSH em vez de FTP, e uma conta isolada por site. O FTP envia as palavras-passe sem cifragem e, sem isolamento, um site comprometido pode infetar todos os outros alojados na mesma conta.
• Nenhuma execução de PHP na pasta de uploads. Essa pasta só deve conter ficheiros multimédia; um ficheiro PHP lá dentro é quase sempre uma web shell.

Em Apache 2.4, coloque o seguinte em wp-content/uploads/.htaccess:

<FilesMatch "\.(?i:php|phtml|phar)$">
    Require all denied
</FilesMatch>

Em nginx, acrescente o seguinte dentro do bloco server, antes do bloco geral location ~ \.php$ (o nginx aplica a primeira location com expressão regular que corresponda ao pedido):

location ~* ^/wp-content/uploads/.*\.(php|phtml|phar)$ {
    deny all;
}

Teste a configuração do nginx com nginx -t antes de a recarregar. Em qualquer dos servidores, confirme depois que as imagens continuam a carregar e que um ficheiro .php de teste na pasta uploads devolve «403 Forbidden».

Núcleo do WordPress, plugins e temas

É nos plugins que se concentra a maioria das vulnerabilidades, por isso este grupo pede uma rotina semanal. O nosso guia sobre plugins WordPress vulneráveis aprofunda o tema.

• Manter ativas as atualizações automáticas de segurança do núcleo. Por predefinição, o WordPress instala em segundo plano as versões menores, que trazem as correções de segurança. Confirme que nenhuma definição nem ferramenta do alojamento as desligou.
• Atualizar plugins e temas em dias, não em meses. Nas vulnerabilidades mais exploradas, a Patchstack mediu uma mediana ponderada de cinco horas até à exploração em massa. As atualizações automáticas, disponíveis desde o WordPress 5.5, encurtam essa janela nos plugins de baixo risco.
• Apagar o que não é usado. Os ficheiros de um plugin desativado continuam no servidor e podem continuar a ser exploráveis; wp plugin list --status=inactive mostra os candidatos.
• Substituir plugins abandonados e nunca usar cópias «nulled». Nos dados da Patchstack, 46 % das vulnerabilidades não tinham correção no momento da divulgação. Um plugin abandonado pode nunca vir a tê-la, e uma cópia pirateada não recebe atualização nenhuma.
• Desativar o editor de ficheiros do painel. define( 'DISALLOW_FILE_EDIT', true ); no wp-config.php remove os editores de ficheiros de temas e de plugins; assim, quem roubar um acesso de administrador não consegue simplesmente colar código num ficheiro do tema.

Contas e inícios de sessão

Um administrador pode instalar plugins, ou seja, executar código no servidor. As funções predefinidas (Administrador, Editor, Autor, Colaborador, Subscritor) facilitam a aplicação do princípio do privilégio mínimo.

• Palavras-passe únicas e autenticação de dois fatores para todos os administradores e editores. Os ataques de credential stuffing testam precisamente palavras-passe divulgadas e reutilizadas. O núcleo do WordPress não inclui 2FA; o nosso guia de autenticação de dois fatores explica as opções.
• Uma conta pessoal por pessoa, com a função mais baixa que sirva. Acessos partilhados «da agência» escondem quem fez o quê e não se conseguem revogar de forma limpa.
• Remover contas antigas e palavras-passe de aplicação sem uso. Ex-funcionários e antigas agências mantêm o acesso até alguém o eliminar; as palavras-passe de aplicação (Application Passwords, desde o WordPress 5.6) aparecem no perfil de cada utilizador.
• Limitar as tentativas de login e desligar o XML-RPC se nada o usar. O XML-RPC vem ativo por predefinição e aceita palavras-passe fora do formulário de login normal. Verifique antes se algum plugin ou aplicação ainda depende dele.

Monitorização e deteção

Só é possível cumprir um prazo de notificação de 72 horas quando a violação chega a ser detetada.

• Análises periódicas de malware e de integridade dos ficheiros. Ficheiros PHP novos em uploads, ficheiros do núcleo alterados e código ofuscado são vestígios típicos de um comprometimento. wp core verify-checksums compara os ficheiros do núcleo com os checksums oficiais do WordPress.org. Veja os 12 sinais de que um site foi pirateado.
• Registos de atividade e alertas para novos administradores. Contas de administrador ocultas são uma forma comum de os atacantes manterem o acesso. Os registos ajudam a reconstituir um incidente; defina um prazo de conservação, porque contêm endereços IP.
• Alertas de vulnerabilidades para os plugins efetivamente instalados. Uma base de dados de vulnerabilidades, por exemplo da WPScan ou da Patchstack, avisa quando um dos plugins em uso tem um problema conhecido.
• Google Search Console e monitorização de disponibilidade. A Search Console assinala os problemas de segurança que a Google deteta no site, como spam injetado; a monitorização de disponibilidade (uptime) apanha as falhas de serviço.

O plugin Security Audit & Compliance da secaudit.eu automatiza várias destas verificações — integridade de ficheiros, assinaturas de malware, administradores ocultos, plugins desatualizados, palavras-passe fracas e definições de hardening — e associa os resultados ao art. 32.º do RGPD e ao art. 21.º da NIS2.

Cópias de segurança e recuperação

O art. 32.º, n.º 1, alínea c), do RGPD exige a capacidade de restabelecer atempadamente a disponibilidade e o acesso aos dados pessoais após um incidente. Só cópias de segurança testadas cumprem essa promessa.

• Cópias automáticas dos ficheiros e da base de dados, pelo menos diárias em sites ativos. Encomendas e formulários mudam todos os dias; uma cópia com uma semana perde-os.
• Pelo menos uma cópia fora do servidor e fora de alcance. Um arquivo de backup na raiz web pode ser descarregado por quem lhe adivinhar o nome, e uma cópia que o próprio site consegue apagar também pode ser apagada por um atacante.
• Testar um restauro pelo menos duas vezes por ano. Uma cópia que nunca foi restaurada é uma esperança, não um plano — e o art. 32.º, n.º 1, alínea d), pede que as medidas sejam testadas regularmente.
• Um plano de incidentes numa só página. Quem decide, quem contacta o alojamento, onde estão as cópias limpas e como notificar uma violação de dados em 72 horas. O nosso plano de remoção de malware trata da limpeza.

Documentação e conformidade

Nos termos do art. 5.º, n.º 2, do RGPD, é preciso conseguir demonstrar as medidas adotadas. Bastam registos curtos e datados.

• Um inventário de plugins, temas, serviços externos e acessos. Não se consegue corrigir nem rever o que não se conhece. Pedidos a terceiros, como o Google Fonts carregado a partir dos servidores da Google, também entram na lista.
• Contratos de subcontratação com o alojamento e com a agência. Quem trata dados pessoais por conta da empresa, incluindo uma agência com acesso de administrador, precisa de um contrato nos termos do art. 28.º do RGPD.
• Um registo de violações e incidentes. O art. 33.º, n.º 5, obriga a documentar todas as violações de dados pessoais, incluindo as que não tiveram de ser notificadas.
• Provas datadas, revistas pelo menos uma vez por ano. Registos de atualizações, relatórios de análise e testes de restauro mostram que as medidas funcionam na prática.

Como esta checklist de segurança WordPress se relaciona com o RGPD e a NIS2

O art. 32.º, n.º 1, do RGPD exige medidas técnicas e organizativas adequadas, tendo em conta as técnicas mais avançadas, os custos e o risco. O art. 21.º, n.º 2, da Diretiva NIS2 enumera dez medidas mínimas para as entidades abrangidas.

A NIS2 abrange sobretudo médias e grandes empresas dos setores enumerados, e os pormenores variam de país para país; por isso, convém consultar a lei nacional que transpõe a NIS2. Os fornecedores mais pequenos são afetados de forma indireta, porque as entidades abrangidas têm de gerir a segurança da cadeia de abastecimento e pedir provas. Veja os nossos artigos sobre o art. 32.º do RGPD e o âmbito da NIS2. Para quem vende plugins ou temas, o Regulamento de Ciber-Resiliência acrescenta deveres de fabricante.

Perguntas frequentes

Com que frequência se deve percorrer esta checklist?

Recomendamos uma revisão completa pelo menos uma vez por ano e sempre que haja mudanças importantes, como um novo alojamento ou uma nova agência.

Cumprir a checklist torna o site conforme com o RGPD?

Nenhuma checklist consegue isso por si só. O art. 32.º assenta no risco: uma loja com contas de clientes precisa de mais do que um site institucional. A checklist cobre a base técnica; a documentação explica porque é que essa base é adequada ao risco concreto.

Temos apenas um pequeno site institucional. Isto aplica-se a nós?

Em grande parte, sim. Os ataques automatizados ignoram a dimensão da empresa, e o RGPD aplica-se a partir do momento em que um formulário de contacto recolhe dados pessoais.

Este artigo contém informação geral e não constitui aconselhamento jurídico.