{"id":856,"date":"2026-09-19T11:02:35","date_gmt":"2026-09-19T11:02:35","guid":{"rendered":"https:\/\/100porcentowp.com.br\/central-de-ajuda\/cms\/wordpress-e-seguro-avaliar-antes-de-assumir-site\/"},"modified":"2026-09-19T11:02:35","modified_gmt":"2026-09-19T11:02:35","slug":"wordpress-e-seguro-avaliar-antes-de-assumir-site","status":"publish","type":"post","link":"https:\/\/100porcentowp.com.br\/central-de-ajuda\/seguranca\/wordpress-e-seguro-avaliar-antes-de-assumir-site\/","title":{"rendered":"WordPress \u00e9 seguro? O que avaliar antes de assumir um site"},"content":{"rendered":"

Voc\u00ea aceitou cuidar do site de um cliente e, na primeira semana, o s\u00f3cio dele pergunta: “mas WordPress \u00e9 seguro?”. A pergunta vem junto com um site que voc\u00ea n\u00e3o montou, com plugins que voc\u00ea n\u00e3o escolheu e com um hist\u00f3rico que ningu\u00e9m documentou. Responder “sim” ou “n\u00e3o” \u00e9 f\u00e1cil e in\u00fatil. O que o cliente precisa ouvir \u00e9 em que camadas mora o risco real e o que voc\u00ea vai fazer com cada uma antes de assinar o contrato de manuten\u00e7\u00e3o.<\/p>\n

Ao longo deste texto, a pergunta “WordPress \u00e9 seguro” aparece menos como d\u00favida filos\u00f3fica e mais como crit\u00e9rio de decis\u00e3o: o que olhar, em que ordem, e quando a resposta honesta \u00e9 recusar o site.<\/p>\n

O que a pergunta “WordPress \u00e9 seguro” realmente quer dizer<\/h2>\n

Quem pergunta se WordPress \u00e9 seguro normalmente est\u00e1 pensando em tr\u00eas coisas diferentes ao mesmo tempo: se o site vai ser invadido, se os dados dos visitantes vazam e se o cliente vai ter preju\u00edzo de imagem. S\u00e3o riscos distintos, com donos distintos.<\/p>\n

O n\u00facleo do WordPress \u00e9 mantido por uma equipe de seguran\u00e7a dedicada e recebe corre\u00e7\u00f5es com frequ\u00eancia. Isso n\u00e3o significa que ele seja invulner\u00e1vel: significa que falhas conhecidas costumam ser corrigidas r\u00e1pido. O problema \u00e9 que a corre\u00e7\u00e3o s\u00f3 chega ao site se algu\u00e9m instalar. E \u00e9 a\u00ed que a pergunta deixa de ser sobre a plataforma e passa a ser sobre o processo de quem administra.<\/p>\n

Por isso, a resposta \u00fatil n\u00e3o \u00e9 “sim” nem “n\u00e3o”. \u00c9: WordPress \u00e9 t\u00e3o seguro quanto a configura\u00e7\u00e3o que voc\u00ea herdou, e essa configura\u00e7\u00e3o pode ser auditada.<\/p>\n

As cinco camadas que respondem pela seguran\u00e7a real<\/h2>\n

Quando um site \u00e9 comprometido, a causa quase nunca \u00e9 uma falha desconhecida no n\u00facleo. Na pr\u00e1tica, o invasor entra por uma dessas cinco portas, e cada uma tem um respons\u00e1vel diferente.<\/p>\n\n\n\n\n\n\n\n\n\n
Camada<\/th>\nQuem responde<\/th>\nO que observar<\/th>\n<\/tr>\n<\/thead>\n
N\u00facleo do WordPress<\/td>\nEquipe do WordPress + voc\u00ea (atualizar)<\/td>\nVers\u00e3o atual, atualiza\u00e7\u00f5es autom\u00e1ticas de seguran\u00e7a ativas<\/td>\n<\/tr>\n
Tema<\/td>\nQuem montou o site<\/td>\nTema pago com licen\u00e7a ativa ou tema abandonado h\u00e1 anos<\/td>\n<\/tr>\n
Plugins<\/td>\nQuem montou o site + voc\u00ea<\/td>\nQuantidade, origem, data da \u00faltima atualiza\u00e7\u00e3o, plugins sem licen\u00e7a<\/td>\n<\/tr>\n
Hospedagem<\/td>\nProvedor<\/td>\nVers\u00e3o do PHP, isolamento entre contas, backups, WAF<\/td>\n<\/tr>\n
Usu\u00e1rios e acessos<\/td>\nCliente + voc\u00ea<\/td>\nQuantos administradores, senhas fracas, 2FA, contas antigas<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Repare que s\u00f3 a primeira camada \u00e9 responsabilidade direta do projeto WordPress. As outras quatro s\u00e3o decis\u00f5es humanas. \u00c9 exatamente por isso que a seguran\u00e7a do WordPress varia tanto de site para site, mesmo com a mesma vers\u00e3o instalada.<\/p>\n

N\u00facleo: o que d\u00e1 para verificar em minutos<\/h3>\n

No painel, v\u00e1 em Painel \u2192 Atualiza\u00e7\u00f5es e confira a vers\u00e3o. Se o site estiver uma ou duas vers\u00f5es atr\u00e1s, \u00e9 sinal de que ningu\u00e9m olha esse painel h\u00e1 meses. Verifique tamb\u00e9m se as atualiza\u00e7\u00f5es autom\u00e1ticas de seguran\u00e7a est\u00e3o habilitadas. Em muitos sites herdados, algu\u00e9m desativou por medo de quebrar o layout, e o efeito colateral \u00e9 ficar exposto a falhas j\u00e1 corrigidas.<\/p>\n

Se voc\u00ea tem acesso a SSH, o caminho \u00e9 mais direto: wp core version<\/code> mostra a vers\u00e3o, e wp core check-update<\/code> diz o que est\u00e1 pendente. Em hospedagem sem SSH, o painel resolve.<\/p>\n

Tema e plugins: onde mora a maior parte do risco<\/h3>\n

Plugins desatualizados s\u00e3o o vetor mais comum em sites WordPress comprometidos. N\u00e3o \u00e9 opini\u00e3o: \u00e9 o que aparece na pr\u00e1tica de quem faz limpeza de malware. O motivo \u00e9 simples, plugin \u00e9 c\u00f3digo de terceiro rodando com as mesmas permiss\u00f5es do site, e muitos s\u00e3o abandonados pelos autores sem aviso.<\/p>\n

Ao assumir um site, liste todos os plugins e responda para cada um: est\u00e1 ativo? tem atualiza\u00e7\u00e3o pendente? o autor publicou algo nos \u00faltimos doze meses? \u00e9 realmente necess\u00e1rio? Plugins sem uso que continuam instalados, mesmo desativados, ainda ocupam espa\u00e7o e \u00e0s vezes mant\u00eam tabelas e arquivos acess\u00edveis.<\/p>\n

Se houver conflito entre dois plugins de seguran\u00e7a instalados ao mesmo tempo, o comportamento fica imprevis\u00edvel. Vale entender como isolar conflitos entre plugins de seguran\u00e7a<\/a> antes de mexer, porque desativar o plugin errado pode derrubar o login.<\/p>\n

Hospedagem: a camada que o cliente n\u00e3o v\u00ea<\/h3>\n

Duas coisas importam aqui. A primeira \u00e9 a vers\u00e3o do PHP: hospedagens antigas costumam rodar vers\u00f5es sem suporte de seguran\u00e7a. A segunda \u00e9 o isolamento entre contas, porque em servidor compartilhado mal configurado, um site invadido pode alcan\u00e7ar arquivos de outro. Se voc\u00ea administra v\u00e1rios sites no mesmo servidor, esse ponto deixa de ser detalhe e vira risco sist\u00eamico. Comparar planos com esse crit\u00e9rio em mente ajuda a decidir qual hospedagem WordPress aguenta v\u00e1rios sites<\/a> sem espalhar o problema.<\/p>\n

Usu\u00e1rios: o vetor mais subestimado<\/h3>\n

Antes de aceitar o contrato, abra Usu\u00e1rios \u2192 Todos os usu\u00e1rios. \u00c9 comum encontrar ex-funcion\u00e1rios, ag\u00eancias antigas e contas de teste ainda com perfil de administrador. Cada uma \u00e9 uma porta. Se aparecer uma conta que ningu\u00e9m reconhece, trate como incidente: o que fazer com usu\u00e1rio administrador desconhecido no WordPress<\/a> \u00e9 um roteiro de triagem, n\u00e3o de exclus\u00e3o imediata, porque apagar a conta errada pode apagar o rastro do invasor.<\/p>\n

Depois de limpar a lista, revise as senhas das contas restantes. Senha de administrador reutilizada de outro servi\u00e7o \u00e9 uma falha silenciosa: o invasor n\u00e3o precisa quebrar nada, s\u00f3 testar credenciais vazadas em outro lugar. Vale seguir um m\u00e9todo para proteger a senha de admin do WordPress<\/a> sem travar o acesso do cliente.<\/p>\n

Como transformar isso em uma avalia\u00e7\u00e3o antes de aceitar o contrato<\/h2>\n

N\u00e3o fa\u00e7a a auditoria depois de assinar. Fa\u00e7a antes, e cobre por ela se for o caso. Uma sequ\u00eancia que funciona:<\/p>\n

    \n
  1. Pe\u00e7a acesso de administrador e acesso \u00e0 hospedagem, mesmo que tempor\u00e1rio. Sem hospedagem, voc\u00ea n\u00e3o v\u00ea PHP, logs nem backups.<\/li>\n
  2. Rode um teste em ambiente de staging ou clone. Nunca avalie no site em produ\u00e7\u00e3o, porque desativar plugin para testar derruba o site do cliente.<\/li>\n
  3. Liste vers\u00e3o do n\u00facleo, tema, todos os plugins e a data da \u00faltima atualiza\u00e7\u00e3o de cada um.<\/li>\n
  4. Verifique a lista de usu\u00e1rios administradores e a data do \u00faltimo login de cada um.<\/li>\n
  5. Confira se existe backup recente e se ele foi testado. Backup que nunca foi restaurado n\u00e3o \u00e9 backup, \u00e9 esperan\u00e7a.<\/li>\n
  6. Cheque a vers\u00e3o do PHP e se a hospedagem oferece algum tipo de firewall ou monitoramento.<\/li>\n
  7. Documente o que encontrou e o que recomenda. Esse documento \u00e9 o que sustenta a conversa com o cliente.<\/li>\n<\/ol>\n

    Se o site j\u00e1 d\u00e1 sinais de comprometimento, a avalia\u00e7\u00e3o muda de natureza. Antes de otimizar qualquer coisa, \u00e9 preciso confirmar se o WordPress foi invadido e agir na ordem certa<\/a>. Limpar sem entender a entrada garante reinfec\u00e7\u00e3o.<\/p>\n

    Quando a resposta honesta \u00e9 recusar o site<\/h2>\n

    Existem casos em que assumir o site \u00e9 aceitar um passivo que n\u00e3o \u00e9 seu. Recuse, ou cobre separadamente por uma reconstru\u00e7\u00e3o, quando:<\/p>\n