WordPress continua sendo o sistema de gerenciamento de conteúdo mais utilizado no Brasil e no mundo, o que o torna um alvo permanente de automações maliciosas. Não se trata de uma fragilidade intrínseca da plataforma, mas sim da superfície de ataque exposta por configurações negligenciadas. Este checklist organiza as ações mais relevantes em ordem de prioridade, com base nas recomendações do CERT.br [1][2] e em boas práticas consolidadas da comunidade de segurança WordPress [3].
Por que um checklist estruturado faz diferença
A segurança de um site WordPress não depende de uma única medida mágica, mas da combinação de várias camadas de proteção aplicadas de forma consistente. Quando um administrador atua de forma reativa — instalando um plugin de segurança apenas após uma invasão —, o custo de recuperação costuma ser desproporcionalmente alto. Um checklist estruturado permite que você audite periodicamente seu ambiente, identifique gaps antes que sejam explorados e documente as decisões tomadas. A própria Cartilha de Segurança para Internet do CERT.br [1] enfatiza que a prevenção e a adoção de boas práticas proativas são sempre mais eficientes do que a remediação tardia. Na prática, ter uma lista verificável transforma segurança de algo vago em um processo gerenciável.
Atualizações: o fundamento que nunca pode ser ignorado
Vulnerabilidades em plugins, temas e no próprio core do WordPress são divulgadas publicamente com frequência. Assim que um patch é lançado, ferramentas automatizadas de escaneamento começam a procurar sites que ainda não atualizaram. Manter o core, os temas e os plugins atualizados é, sem exagero, a ação individual com maior retorno em segurança. Desative e remova plugins e temas que não estejam em uso: cada linha de código inativa é potencialmente uma porta de entrada. Configure atualizações automáticas para o core e, quando possível, para plugins de fontes confiáveis. Antes de atualizar em produção, teste em um ambiente de staging para evitar quebramento de funcionalidades. Registre em seu checklist a data da última verificação de versões e o número de componentes desativados que foram removidos.
Autenticação forte e gestão de credenciais
O fascículo sobre contas e senhas da Cartilha do CERT.br [2][6] deixa claro que credenciais fracas são o vetor inicial mais explorado em ataques a plataformas web. No contexto WordPress, isso significa eliminar o usuário padrão “admin”, impor senhas com no mínimo 12 caracteres e exigir autenticação em dois fatores (2FA) para todas as contas com privilégios de administrador. Limitar as tentativas de login — seja via plugin ou via configuração de servidor — reduz drasticamente a eficácia de ataques de força bruta. Considere também alterar a URL padrão de login (wp-login.php) apenas como camada adicional, nunca como única medida, pois isso não substitui credenciais fortes. Revise periodicamente a lista de usuários e remova contas sem uso ou com permissões desnecessariamente elevadas.
Proteção em camadas: firewall e hardening do servidor
Um firewall de aplicação web (WAF) atua como filtro entre o tráfego da internet e seu WordPress, bloqueando requisições que correspondam a padrões conhecidos de ataque — como injeção de SQL, cross-site scripting e tentativas de enumeração de usuários. Soluções como Wordfence, Sucuri ou regras personalizadas em servidores Nginx/Apache cumprem bem essa função. Além do WAF, o hardening do servidor inclui desabilitar a execução de PHP em diretórios que não precisam dela (como /wp-content/uploads/), restringir o acesso ao arquivo wp-config.php e configurar corretamente as permissões de arquivos (644 para arquivos, 755 para diretórios). Headers de segurança — como X-Content-Type-Options, X-Frame-Options, Referrer-Policy e Content-Security-Policy — complementam a defesa no nível do navegador [5].
Backup automatizado e testado com frequência
O fascículo sobre backup do CERT.br [1][2] estabelece que um backup só é confiável quando é automatizado, armazenado em local separado do servidor de produção e regularmente testado para garantir que a restauração funcione corretamente. No WordPress, um backup completo deve incluir os arquivos do site (especialmente a pasta wp-content) e o banco de dados. Plugins como UpdraftPlus, Duplicator ou soluções em nível de servidor (cPanel backups, snapshots de provedores cloud) são opções viáveis. Defina a frequência com base na dinâmica do seu conteúdo: sites com atualizações diárias precisam de backup diário; sites estáticos podem usar backup semanal. Documente no seu checklist onde os backups estão armazenados, qual a frequência e quando foi a última restauração testada.
HTTPS, certificados TLS e comunicação segura
Operar um site WordPress sem HTTPS em 2026 é inaceitável tanto do ponto de vista de segurança quanto de conformidade. O HTTPS criptografa a comunicação entre o navegador do visitante e o servidor, protegendo credenciais, dados de formulários e sessões contra interceptação. Obtenha um certificado TLS gratuitamente via Let’s Encrypt — a maioria dos provedores de hospedagem oferece integração automática. Após a ativação, force o redirecionamento de todo o tráfego HTTP para HTTPS no nível do servidor (não apenas via plugin). Verifique também se não há conteúdo misto (recursos carregados via HTTP em páginas HTTPS) usando ferramentas de auditoria do navegador. O HSTS (HTTP Strict Transport Security) deve ser configurado para instruir os navegadores a sempre usar HTTPS.
Monitoramento de integridade e detecção de invasões
Mesmo com todas as camadas de prevenção, é preciso assumir que uma invasão pode ocorrer. O monitoramento contínuo permite detectar comprometimentos precocemente, limitando o dano. Ferramentas como o scanner integrado do Wordfence, o Sucuri SiteCheck ou soluções externas de integridade de arquivos comparam o estado atual dos arquivos do WordPress com versões conhecidas e limpas. Configure alertas para notificações de novos usuários criados, alterações em plugins ou temas, e picos anormais de tráfego. Revise os logs de acesso do servidor com regularidade, procurando por padrões suspeitos como requisições repetidas a arquivos sensíveis (wp-config.php.bak, .htaccess, xmlrpc.php). Inclua no checklist a frequência de revisão de logs e a ferramenta de scanner ativa.
Checklist resumido em tabela para auditoria rápida
A tabela abaixo consolida os pontos principais para consultas rápidas durante uma auditoria de segurança. Imprima ou mantenha em formato acessível para verificações periódicas.
| Camada | Ação | Prioridade | Frequência sugerida |
|---|---|---|---|
| Core e componentes | Atualizar WordPress, temas e plugins | Crítica | Semanal ou automática |
| Core e componentes | Remover temas e plugins inativos | Alta | Mensal |
| Autenticação | Eliminar usuário “admin” e impor 2FA | Crítica | Imediata (uma vez) |
| Autenticação | Revisar lista de usuários e permissões | Alta | Mensal |
| Rede e servidor | Configurar WAF e headers de segurança | Alta | Na implantação e após mudanças |
| Rede e servidor | Desabilitar execução de PHP em /uploads/ | Alta | Na implantação (uma vez) |
| Comunicação | Garantir HTTPS com HSTS e sem conteúdo misto | Crítica | Na implantação e trimestral |
| Resiliência | Configurar backup automático off-site | Crítica | Diário ou semanal |
| Resiliência | Testar restauração do backup | Alta | Trimestral |
| Monitoramento | Executar scanner de integridade e revisar logs | Média | Semanal |
Erros comuns que minam toda a proteção
Mesmo administradores experientes cometem erros que neutralizam camadas inteiras de segurança. O mais frequente é instalar um plugin de segurança e considerar o trabalho concluído, sem realizar as configurações básicas de hardening que o plugin requer. Outro erro grave é armazenar backups no mesmo servidor do site: se o servidor for comprometido, o atacante pode destruir ou criptografar os backups junto com o site. Usar temas nulos ou baixados de fontes não oficiais é um risco silencioso, pois código malicioso embutido nesses temas pode passar despercebido por meses. Ignorar a necessidade de testar a restauração de backup é outro ponto crítico: um backup que não pode ser restaurado com sucesso é equivalente a não ter backup. Por fim, delegar acesso administrativo a terceiros sem necessidade ou sem auditar posteriormente cria uma superfície de ataque desnecessária.
Como manter o checklist vivo e atualizado
Um checklist de segurança não é um documento estático. Novas vulnerabilidades são descobertas, a plataforma WordPress evolui e o perfil de ameaças muda ao longo do tempo. Defina um responsável pela segurança do site — mesmo em equipes pequenas, uma pessoa deve ser o ponto focal. Programe revisões trimestrais do checklist para incorporar novas recomendações, remover itens obsoletos e ajustar prioridades. Utilize ferramentas de gestão de tarefas ou planilhas compartilhadas para registrar cada verificação com data e responsável. Quando um incidente ocorrer, use o evento como oportunidade para revisar qual camada falhou e atualizar o checklist para evitar recorrência. A disciplina de manter o checklist vivo é o que diferencia sites que sofrem invasões recorrentes daqueles que mantêm uma postura de segurança consistente.
Perguntas frequentes sobre segurança WordPress
Um site WordPress pequeno realmente precisa de tudo isso?
Sim, mas com proporcionalidade. Sites pequenos são frequentemente alvo de automações que não distinguem tamanho — elas procuram vulnerabilidades conhecidas em massa. O mínimo indispensável é: atualizações em dia, HTTPS, 2FA no acesso administrativo, backup off-site e remoção de componentes inativos. Camadas adicionais como WAF podem ser avaliadas conforme o risco percebido.
Plugins de segurança substituem a necessidade de hardening manual?
Não. Plugins de segurança são ferramentas que auxiliam na implementação de boas práticas, mas não as substituem. Muitas medidas críticas — como permissões de arquivos no servidor, configuração de HSTS e desabilitação de execução de PHP em diretóritos específicos — exigem intervenção no nível do servidor ou da hospedagem, algo que nenhum plugin pode fazer sozinho.
Com que frequência devo testar a restauração do backup?
O ideal é no mínimo a cada três meses. Um backup que nunca foi testado pode conter corrupção silenciosa, estar incompleto ou falhar no processo de restauração por incompatibilidade de versões. O teste periódico é a única forma de ter confiança real na sua estratégia de backup, conforme reforçado pelo CERT.br em seu fascículo específico sobre o tema [1].
Temas premium baixados de sites de terceiros são seguros?
Em geral, não. Temas distribuídos fora dos canais oficiais frequentemente contêm código malicioso embutido — backdoors, redirecionamentos de SEO ou funções de ocultação que são ativadas em momentos específicos. O risco é especialmente alto porque esse código pode não ser detectado por scanners convencionais. Utilize apenas o repositório oficial do WordPress ou fontes comerciais diretamente dos desenvolvedores.
O que fazer se o site já foi invadido?
Isolamento imediato: coloque o site em modo de manutenção e bloqueie o acesso administrativo. Restaure o backup mais recente limpo. Se não houver backup confiável, faça uma limpeza manual com auxílio de um profissional de segurança. Altere todas as senhas e revoke tokens de API. Após a recuperação, conduza uma análise de causa raiz para identificar o vetor de ataque e atualize seu checklist para cobrir essa falha específica.
Fontes
[1] CERT.br — Fascículos da Cartilha de Segurança para Internet
[2] Governo Digital — CERT.br — Centro de Excelência em Privacidade e Segurança
[3] WordPress Security Checklist — Checklist de Segurança WordPress em Português Brasileiro