Por framework
Segurança do WordPress — uma referência de hardening para produção
Uma referência de hardening do WordPress para produção: uma lista de verificação priorizada mais atualizações, gestão de plugins/temas, 2FA de administrador, redução da exposição da administração, wp-config e segredos, arquivos e backups, com uma lista de autoverificação. Defensivo, sem passos de ataque.
Para: qualquer pessoa que opere um site WordPress. Sem passos de ataque aqui — esta é uma referência de trabalho para hardening: uma lista de verificação por ordem de prioridade, orientação por área e autoverificação. Para o panorama entre frameworks, veja o hub de segurança por framework.
Lista de verificação de hardening por ordem de prioridade
Faça esta tabela de cima para baixo. P0 é a prioridade máxima, P1 é a fonte mais frequente de incidentes, P2 é higiene operacional contínua.
P0 ── Pré-requisito (faça primeiro)
Atualizações automáticas / apagar plugins e temas não usados / administrador forte + 2FA
P1 ── Principal fonte de incidentes
Minimizar plugins / reduzir a exposição da administração / backups recuperáveis
P2 ── Higiene operacional
wp-config e segredos / permissões de arquivo / HTTPS, cabeçalhos, atualidade do PHP/dependências
| Prioridade | Controle | Especificidades (WordPress) |
|---|---|---|
| P0 | Atualizações automáticas | Ative atualizações automáticas para o núcleo, plugins, temas. Faça backup antes de atualizações maiores |
| P0 | Apagar o não usado | Apague plugins/temas não usados, não apenas desative (arquivos restantes ainda são alvo) |
| P0 | Administrador forte + 2FA | Senha forte + dois fatores. Evite o nome de usuário admin; papéis de menor privilégio |
| P1 | Minimizar plugins | Avalie a frequência de atualização, a adoção e CVEs conhecidos antes de instalar. Mantenha a contagem baixa |
| P1 | Proteger o login | Limites de tentativas de login. Restrinja a exposição de wp-admin/wp-login.php |
| P1 | Reduzir a exposição | Restrinja o xmlrpc.php se não usado. Suprima a enumeração de usuários via REST API |
| P1 | Backups | Backups recuperáveis offline/separados + testes de restauração + detecção de adulteração |
| P2 | wp-config e segredos | Defina chaves/salts de autenticação, proteja o wp-config.php, desative a exibição de depuração em produção |
| P2 | Permissões de arquivo | ~644 arquivos / 755 diretórios. Proíba a execução de PHP no diretório de uploads |
| P2 | HTTPS/cabeçalhos/atualizações | Force HTTPS, HSTS, etc. Mantenha PHP/BD em versões suportadas |
1. Atualizações (a defesa número um)
A maioria dos ataques ao WordPress são ferramentas automatizadas atingindo uma vulnerabilidade conhecida publicada (CVE) em escala. Então a velocidade de atualização é a sua maior defesa.
- Ative atualizações automáticas para o núcleo, plugins e temas — feche buracos publicados antes que sejam atingidos.
- Para sites importantes, verifique atualizações maiores em staging e faça backup antes de atualizar.
- Uma atualização pulada é uma entrada aberta para ataques automatizados. Não "faça depois".
2. Plugins e temas (superfície de ataque)
Vulnerabilidades de código de terceiros são a maior entrada. A chave é manter a contagem baixa e nunca deixá-los sem cuidado.
- Para qualquer coisa não usada, apague em vez de desativar (arquivos desativados ainda podem ser alvo).
- Antes de instalar, verifique a frequência de atualização, a adoção, a data da última atualização e os CVEs conhecidos. Evite os abandonados.
- Você pode verificar CVEs de plugins com a busca de CVE/KEV. Menos extensões significa menos responsabilidade de atualização e menos superfície de ataque.
3. Contas de administrador e autenticação
A maioria das tomadas de controle é força bruta contra contas de administrador fracas/reutilizadas, ou a reutilização de senhas vazadas.
Comum (perigoso)
- nome de usuário
admin+ senha fraca + sem 2FA - todos são administradores (sem separação de papéis)
- tentativas de login ilimitadas
wp-adminalcançável de qualquer lugar
Correto
- senha forte + 2FA, um nome de usuário diferente de
admin - papéis de menor privilégio (use editor/autor apropriadamente)
- limites de tentativas de login (freie a força bruta)
- quando possível, restrinja de onde
wp-admin/wp-login.phppodem ser alcançados
Para escolher a 2FA veja o que é 2FA; para a rota que visa os administradores veja o que é phishing.
4. Reduzir a exposição (superfície de administração e divulgação)
Os atacantes primeiro procuram uma "entrada usável". Corte recursos não usados e divulgação desnecessária.
- Adicione limites de tentativas de login para reduzir a eficácia da força bruta.
- Restrinja o
xmlrpc.phpse não usado (pode ser uma entrada para amplificação de força bruta e requisições em alto volume). - Suprima a enumeração de usuários via REST API (evite expor nomes de administrador via
?author=etc.). - Desative a listagem de diretórios e reduza a divulgação desnecessária de versão.
- Desative a edição de arquivos a partir da administração (
DISALLOW_FILE_EDIT) para dificultar a adulteração após uma invasão.
5. wp-config e segredos (P2)
- Defina as chaves/salts de autenticação únicas e proteja o
wp-config.phpcom permissões apropriadas (nunca legível por todos). - Mantenha segredos como credenciais de BD fora da superfície pública. Não deixe backups ou exportações em um diretório público (→ mantenha segredos fora de diretórios públicos).
- Em produção, desative a exibição de depuração (
WP_DEBUG_DISPLAYdesligado). Não vaze detalhes internos via erros.
6. Arquivos e uploads (P2)
- Permissões de arquivo de aproximadamente 644 arquivos / 755 diretórios, e mais rígidas para o
wp-config.php. Nunca deixe nada gravável por todos. - Não permita a execução de PHP no diretório de uploads (defesa contra web-shell). Valide o tipo e o tamanho do upload.
- Use detecção de adulteração (monitoramento de mudanças de arquivos) para identificar cedo alterações após uma invasão.
7. HTTPS, cabeçalhos, backups (P2)
- Force HTTPS + HSTS. Resolva conteúdo misto.
- Adicione cabeçalhos de segurança (verifique o seu próprio site com o verificador de cabeçalhos de segurança).
- Mantenha backups offline/imutáveis + testes de restauração para poder recuperar (→ o essencial de backup). A última linha contra ransomware e pichação.
8. Hospedagem e dependências (P1–P2)
- Mantenha PHP e o banco de dados em versões suportadas. Não deixe versões EOL no lugar.
- Conheça o status de patches da sua hospedagem (em hospedagem compartilhada, isso inclui a resposta do provedor).
- Um WAF é um complemento — firme a base (atualizações, minimização, autenticação, backups) primeiro.
Verifique: o seu WordPress está de fato endurecido?
Construí-lo não é o fim — só está pronto depois que você verificou. Estas são autoverificações defensivas contra o seu próprio site.
Segredos e config não estão expostos
/wp-config.php não retorna seu conteúdo, e que backups (.zip/.sql) ou arquivos do tipo .env não podem ser baixados por URL.Nomes de administrador e versões não vazam
?author=1 e semelhantes não expõem um nome de usuário de administrador, e que a listagem de diretórios está desligada.Proteção de login e 2FA funcionam
admin restante permanece.Atualizações, backups, cabeçalhos
A visão deste site: gerencie 'extensões e descuido', não o núcleo
O que funciona para o WordPress não é configuração chamativa, mas a disciplina operacional de "não adicionar extensões demais, não deixá-las sem cuidado." Plugins são convenientes, mas cada um adiciona uma responsabilidade de continuar atualizando. O centro de gravidade é trabalhar a tabela acima de cima para baixo — automatize atualizações, mantenha plugins no mínimo e defenda com autenticação forte e backups recuperáveis. Parece específico do WordPress, mas é na verdade a base universal (atualidade das dependências, superfície pública mínima, autenticação, recuperação) aplicada.
Leia a seguir
- Hub: segurança por framework · segurança do Laravel
- Prática: o manual de resposta a vulnerabilidades · o essencial de backup
- Segredos/autenticação: mantenha segredos fora de diretórios públicos · o que é 2FA · o que é phishing
- Ferramentas: verificador de cabeçalhos de segurança · busca de CVE/KEV
FAQ
QO que devo fazer primeiro para proteger o WordPress?
Os três itens P0: (1) ative atualizações automáticas para o núcleo, plugins e temas, para que vulnerabilidades conhecidas publicadas (CVEs) sejam fechadas antes de serem atingidas; (2) apague plugins/temas não usados (não apenas desative) para cortar a superfície de ataque; (3) proteja as contas de administrador com uma senha forte e autenticação de dois fatores (2FA), e evite o nome de usuário admin. Esses três sozinhos detêm a maioria dos ataques automatizados. Em seguida, reduza a exposição da administração e configure backups.
QQuantos plugins são demais?
A regra é 'só o mínimo de que você precisa'. Cada plugin amplia a superfície de ataque e uma 'responsabilidade de continuar atualizando'. Antes de instalar, verifique a frequência de atualização, a adoção, a data da última atualização e as vulnerabilidades conhecidas; e o que você não usa, apague em vez de desativar (arquivos desativados ainda podem ser alvo de vulnerabilidade). O mesmo vale para os temas.
QDevo desativar o xmlrpc.php?
Se você não o usa, restringir ou desativar é recomendado. O xmlrpc.php serve postagem remota e pingbacks, mas também pode ser uma entrada para amplificação de força bruta e requisições em alto volume. Se você usa recursos que precisam dele (algumas integrações de aplicativos), limite-o aos métodos de que precisa ou proteja-o com limites de taxa/IP. Verifique primeiro se você realmente o usa.
QUm plugin de segurança me deixa seguro?
Um plugin de segurança ajuda, mas não é uma bala de prata. Aparafusar um enquanto a base (atualizações automáticas, plugins mínimos, autenticação forte de administrador, backups, exposição reduzida da administração) está faltando não fecha os buracos. Trabalhe a lista de verificação desta página primeiro e depois use um plugin para complementar coisas como limites de tentativas de login e detecção de adulteração.
QQual é o mínimo absoluto?
(1) atualizações automáticas, (2) apagar plugins/temas não usados, (3) senha forte + 2FA para administradores, (4) limites de tentativas de login e exposição reduzida da administração, (5) backups offline recuperáveis + detecção de adulteração. Esses cinco detêm a maioria dos ataques automatizados. Veja a lista de verificação e as seções acima para o detalhe.