Segurança em WordPress: os erros que podem colocar seu site em risco

Segurança em WordPress não se resume a instalar um certificado SSL e considerar o problema resolvido. Um site pode carregar normalmente em HTTPS, utilizar firewall e até contar com plugins de proteção e, ainda assim, permanecer vulnerável a falhas técnicas, configurações incorretas ou componentes desatualizados.

Esse foi um dos pontos discutidos por Amanda Noronha, especialista em SEO Técnico, e John Martin, apresentador do Martincast e fundador da agência SEO Martin. No corte, os dois mostram como problemas de segurança podem ir além de uma invasão: eles também podem afetar experiência do usuário, tráfego, rastreamento e até a forma como mecanismos de busca interpretam o site.

Segurança em WordPress começa com HTTPS bem configurado

O certificado SSL é uma das camadas mais básicas de segurança de um site. Ele permite que a comunicação entre navegador e servidor seja criptografada e possibilita que o site opere em HTTPS.

Mas simplesmente possuir um certificado ativo não significa que toda a configuração esteja correta.

Um dos problemas comentados no episódio envolve sites que continuam permitindo acesso tanto pela versão HTTP quanto pela HTTPS. Em situações assim, o Google pode encontrar URLs diferentes com conteúdos equivalentes, o que exige atenção a redirecionamentos e canonicalização.

Amanda relata um caso em que um grande portal apresentava alertas de segurança aos usuários por problemas relacionados ao certificado. O impacto não ficou restrito à experiência de navegação.

“Mexeu com todas as métricas. Ninguém estava entendendo nada.”

Segundo o relato, usuários que insistiam em continuar após o aviso de segurança acabavam alterando a forma como determinadas visitas eram registradas. Além disso, mesmo depois da correção do certificado, ainda existiam páginas HTTP aparecendo na indexação.

Esse exemplo mostra como segurança, SEO técnico e mensuração podem estar diretamente conectados.

HTTP e HTTPS não devem competir entre si

Uma prática fundamental é estabelecer uma versão oficial do site.

Se o endereço correto é:

'https://www.exemplo.com'

as demais variações devem direcionar corretamente para essa versão, incluindo combinações com HTTP ou sem “www”, de acordo com a configuração definida para o projeto.

O ideal é que o redirecionamento aconteça no servidor ou em uma camada anterior à aplicação. Quando isso não é possível, também é importante revisar outros sinais técnicos, como a tag canonical.

O problema se torna especialmente delicado quando o site abre em HTTPS, mas informa aos mecanismos de busca que a versão canônica está em HTTP.

Esse tipo de inconsistência pode acontecer, por exemplo, quando as configurações internas do WordPress foram originalmente gravadas com HTTP.

Plugins de SEO podem utilizar essas informações como referência e gerar canonicals incorretos em diversas páginas.

Por isso, uma auditoria técnica deve verificar:

• endereço do WordPress;
• endereço do site;
• redirecionamentos HTTP para HTTPS;
• URLs canônicas;
• sitemap;
• links internos;
• configurações no banco de dados, quando necessário.

SSL não é sinônimo de site protegido

Um dos principais aprendizados do corte é simples: certificado SSL é apenas uma camada de segurança.

Um site também precisa se proteger contra tentativas de invasão, ataques automatizados, vulnerabilidades em plugins, falhas de configuração e credenciais comprometidas.

John e Amanda citam duas ferramentas bastante utilizadas em projetos WordPress: Cloudflare e Wordfence.

A diferença entre as duas ajuda a entender o conceito de proteção em camadas. A Cloudflare pode atuar antes que determinada requisição chegue ao servidor de origem. Isso permite bloquear ou filtrar tráfego indesejado em uma camada externa.

Já soluções instaladas diretamente no WordPress atuam dentro da aplicação. Na prática, combinar diferentes mecanismos cria múltiplas barreiras.

Isso não significa que a invasão se torna impossível. O próprio John relata um caso em que um site protegido por diferentes recursos de segurança foi comprometido por meio de uma vulnerabilidade relacionada a arquivos presentes na instalação.

O invasor conseguiu inserir código malicioso no site e gerar redirecionamentos para páginas de spam. A lição é importante: nenhuma ferramenta isolada substitui uma rotina de manutenção.

Plugins desatualizados são um risco desnecessário

WordPress é um ecossistema composto por núcleo, temas e plugins. Cada um desses componentes pode receber correções de segurança ao longo do tempo.

Por isso, manter uma instalação sem atualizações por meses ou anos aumenta o risco operacional.

No episódio, John comenta ter encontrado um site em que WordPress e plugins não eram atualizados havia aproximadamente três anos.

O problema, nesse estágio, vai além da segurança. Atualizar tudo de uma vez também pode gerar incompatibilidades ou quebrar funcionalidades.

Por isso, uma boa rotina de manutenção deve considerar:

1. backups antes de mudanças relevantes;
2. atualização frequente de plugins e temas;
3. remoção de plugins sem uso;
4. testes após atualizações;
5. ambiente de homologação quando a complexidade do projeto justificar.

Quanto mais tempo um site permanece sem manutenção, maior tende a ser o esforço necessário para normalizá-lo.

Backup também é uma política de segurança

Backup costuma ser tratado como uma tarefa operacional. Na prática, ele faz parte da estratégia de segurança. Amanda destaca esse ponto ao falar sobre redundância.

“Você tem que criar uma redundância para poder se proteger de qualquer tipo de problema.”

Mesmo com boas práticas, incidentes podem acontecer. Um site pode sofrer invasão, uma atualização pode apresentar erro, arquivos podem ser corrompidos ou uma configuração inadequada pode tornar a aplicação indisponível.

Nessas situações, um backup recente reduz drasticamente o impacto operacional. O importante não é apenas possuir uma cópia. Também é necessário considerar frequência, armazenamento e capacidade de restauração.

Sites que recebem alterações constantes podem exigir backups mais frequentes do que sites institucionais com poucas mudanças.

E um backup que nunca foi testado pode não oferecer a segurança esperada no momento de uma emergência.

Segurança também envolve infraestrutura

Outro ponto importante da conversa é que segurança não significa apenas impedir invasões. Disponibilidade também faz parte da confiabilidade de um site.

Amanda relata o caso de uma instituição que recebeu um grande volume de acessos após uma divulgação na televisão. Em poucos minutos, o site ficou indisponível porque o servidor não suportou o aumento repentino de demanda.

No ano seguinte, a equipe se preparou previamente e aumentou a capacidade de processamento do servidor. O site conseguiu suportar o novo pico.

Esse exemplo mostra por que planejamento de infraestrutura é relevante principalmente para sites sujeitos a campanhas, mídia, eventos, lançamentos ou grandes picos de tráfego.

Um site pode estar protegido contra ataques e ainda assim ficar fora do ar simplesmente porque sua infraestrutura não suporta a demanda.

Como reduzir os riscos do seu site WordPress

Não existe uma configuração única capaz de eliminar completamente os riscos. O objetivo é trabalhar em camadas.

Certificado SSL, redirecionamentos, firewall, atualizações, backups, controle de acesso e infraestrutura devem fazer parte de uma mesma estratégia.

Uma boa rotina começa com algumas perguntas simples:

1. Seu certificado é renovado automaticamente?
2. Todas as URLs HTTP redirecionam para HTTPS?
3. Os canonicals utilizam a versão correta do domínio?
4. Plugins e temas estão atualizados?
5. Existe proteção contra tráfego malicioso?
6. Os backups são feitos regularmente?
7. Existe uma cópia armazenada fora do servidor principal?
8. Seu servidor suporta um aumento inesperado de tráfego?

Responder essas perguntas já ajuda a identificar boa parte dos riscos mais comuns em projetos WordPress.