Blog

Nesta parte começo a dar as dicas iniciais para você ter um site em WordPress seguro e que evite ao máximo ser invadido.

Se conseguir implementar ao menos esses itens, seu site já terá dado um passo significativo em termos de segurança.

De acordo com o WPScan, um dos maiores bancos de dados de vulnerabilidades do WordPress, já foram catalogadas mais de 4 mil vulnerabilidades conhecidas.

Esse número se alinham com análises do Wordfence (falaremos dele mais a frente), uma das soluções de segurança mais utilizadas na plataforma.

Segundo seus relatórios, ao proteger o site contra vulnerabilidades em plugins e ataques de força bruta (quando milhares de combinações de senha são testadas automaticamente) é possível mitigar mais de 70% dos riscos mais comuns.

Então, vamos as dicas iniciais.

A segurança de um site WordPress não começa no painel administrativo. Na prática, ela começa muito antes, ainda na escolha do servidor e na forma como a instalação é realizada.

Pequenas decisões tomadas nesse momento inicial já ajudam a reduzir significativamente as brechas mais exploradas em ataques automatizados.

1. Servidor

A experiência do desenvolvedor é essencial aqui.

Tenho clientes hospedados em vários servidores diferentes e temos uma ideia de quais os mais adequados para cada instalação.

Portanto, é importante pesquisar e ver comentários e outras informações. Lembro de entrar no administrador de um servidor, até bem famoso aqui do Brasil, e que estava rodando sistemas desatualizados há mais de 5 anos. Na minha opinião algo inadimissível e uma baita brecha de segurança.

Lembrando que devemos analisar a situação no momento. No passado, esse servidor citado tinha um bom nome no mercado. Isso varia muito com o tempo.

2. Instalação bem feita

Embora muitos provedores ofereçam instalação automática do WordPress, nem sempre essa é a opção mais segura.

Essas instalações costumam vir com configurações padrão, permissões amplas e pouca flexibilidade.

Por isso, baixar o WordPress diretamente do repositório oficial, configurar o ambiente no servidor e realizar a instalação manualmente costuma ser uma abordagem mais segura e controlada.

Se você ainda não instalou o WordPress passe para o item 2.1 e siga o passo a passo. Caso contrário, será necessário possuir um conhecimento técnico maior e talvez a solução listada em 2.2 não seja de fácil implementação.

Nesta segunda hipótese não recomendo se arriscar em desconfigurar o site e esta etapa poderá ser “pulada”.

2.1. Implementação durante a Instalação do WordPress

Altere o prefixo padrão do banco de dados

Durante o processo de instalação do WordPress, um dos ajustes mais simples, e também mais negligenciados, é a definição do prefixo das tabelas do banco de dados.

Embora passe despercebido por muitos usuários, esse detalhe já é solicitado logo na instalação e pode ser alterado com facilidade nesse momento inicial.

Por padrão, o WordPress utiliza o prefixo wp_, o que torna a estrutura do banco de dados previsível. Basta substituir o valor por algo menos óbvio, tal como wp34$cs_.

Como consequência, ataques automatizados de injeção SQL costumam assumir que esse prefixo está presente, facilitando tentativas de exploração.

Ao definir um prefixo diferente ainda na instalação, você adiciona uma camada extra de proteção.

Embora essa medida não elimine vulnerabilidades por si só, ela dificulta ataques automatizados e reduz a superfície de risco logo no início do projeto.

Quando essa alteração é feita durante a instalação, nenhuma ação adicional é necessária, pois as tabelas já serão criadas com o novo prefixo.

2.2. Implementação após a Instalação do WordPress

Se for feita após a intalação, duas soluções são possíveis, e ambas exigem um certo conhecimento para evitar problemas de funcionamento do site.

Caso não se sinta seguro, sugiro pular esta etapa.

• Manualmente via alteração de arquivos e SQL
• Utilizando plugin

Alteração do prefixo em instalações já existentes manualmente

Este processo exige mais atenção e um conhecimento técnico razoável. Se não for o seu caso verifique a próxima solução.

Será necessário alterar o valor no wp-config.php e depois alterar as tabelas no banco de dados via sql.

O prefixo das tabelas armazenado no arquivo wp-config.php está na seguinte linha:

$table_prefix = 'wp_';

Nesse ponto, basta substituir o valor por algo menos óbvio.

Em seguida é necessário também renomear todas as tabelas do banco de dados e atualizar referências internas utilizadas pelo próprio WordPress.

Para renomear as tabelas, utilize uma consulta SQL como esta, repetindo o comando para cada tabela existente:

RENAME TABLE `wp_links` TO `novoprefixo_links`;

Após renomear todas as tabelas, é preciso atualizar as referências armazenadas no banco.

Na tabela usermeta, execute:

UPDATE `novoprefixo_usermeta`
SET `meta_key` = REPLACE(`meta_key`, 'wp_', 'novoprefixo_');

Em seguida, ajuste a tabela options com o comando abaixo:

UPDATE `novoprefixo_options`
SET `option_name` = 'novoprefixo_user_roles'
WHERE `option_name` = 'wp_user_roles';

Esse procedimento garante que o WordPress reconheça corretamente o novo prefixo em todas as suas estruturas internas.

Uso de plugins para facilitar o processo

Para quem prefere uma abordagem mais prática ou não se sente confortável executando comandos SQL manualmente, existem plugins confiáveis que automatizam esse processo com segurança, mas lembre-se de fazer um backup antes. Nenhum sistema é 100% garantido.

Entre os mais conhecidos estão:

• iThemes Security
• WP Security Audit Log (em conjunto com módulos de hardening)
• All In One WP Security & Firewall

Esses plugins cuidam da alteração do prefixo, da atualização das tabelas e das referências internas automaticamente.

Ainda assim, mesmo ao usar plugins, é fundamental garantir que o processo seja feito com atenção e que o prefixo configurado no wp-config.php corresponda exatamente ao utilizado no banco de dados.

Em resumo, alterar o prefixo padrão das tabelas é uma medida simples quando feita na instalação, mas exige mais cuidados quando feita manualmente ou com o auxílio de plugins.

Ela é eficaz e altamente recomendada dentro de uma estratégia básica de segurança no WordPress.

3. Nunca utilize “admin” como nome de usuário

Ainda hoje, muitos sites WordPress utilizam “admin” como nome de usuário.

Esse é sempre o primeiro login testado em ataques de força bruta. Portanto, manter esse usuário ativo é facilitar o trabalho do invasor.

A solução é simples: crie um novo usuário com perfil de Administrador, utilizando um nome menos previsível e um e-mail diferente.

Em seguida, faça login com o novo usuário, exclua o antigo e atribua todo o conteúdo a essa nova conta.

4. Senhas fortes não são opcionais

Senhas fracas continuam entre as principais causas de invasão.

O ideal é utilizar senhas longas, com letras maiúsculas e minúsculas, números e caracteres especiais.

Sempre que possível, utilize um gerenciador de senhas para evitar reutilização em vários serviços.

5. Altere o caminho de acesso ao Administrador do site

Por padrão, o WordPress utiliza URLs amplamente conhecidas para acesso ao painel administrativo, como /wp-login.php ou /wp-admin/. Inclusive, ao acessar /wp-admin/, o sistema redireciona automaticamente para a tela de login.

Esse comportamento não representa uma falha de segurança em si. No entanto, ele facilita ataques automatizados, já que robôs e scripts maliciosos sabem exatamente onde tentar autenticação.

Como consequência, mesmo sites pequenos acabam sofrendo milhares de tentativas de login diariamente.

Logo, ao alterar o caminho de acesso ao administrador, você adiciona uma camada extra de proteção baseada em obscurecimento.

Embora essa técnica não substitua outras medidas de segurança, ela reduz significativamente ataques de força bruta e varreduras automáticas.

Alteração do URL de login via plugin

Uma das formas mais simples de alterar o endereço de acesso ao painel é utilizando plugins específicos para essa finalidade.

O iThemes Security, por exemplo, permite modificar o caminho de login diretamente nas configurações, sem necessidade de intervenção manual em arquivos do sistema.

Outra alternativa bastante popular é o WPS Hide Login. Esse plugin é leve, não altera arquivos do núcleo do WordPress e funciona redefinindo o endpoint de login.

Ao tentar acessar /wp-login.php, o visitante recebe um erro 404, enquanto o acesso passa a funcionar apenas pelo novo caminho configurado.

Essas soluções são ideais para quem busca praticidade e baixo risco de erro.

Alteração do URL de login via function.php com novo caminho de acesso

Para quem prefere evitar plugins adicionais ou deseja maior controle, também é possível alterar o acesso ao login por meio de código.

Isso pode ser feito adicionando regras específicas no arquivo functions.php preferencialmente em um tema filho (isso é de relativa importância para evitar perda de código nas atualizações).

No entanto, essa abordagem exige cuidado.

Implementações mal feitas podem causar bloqueio do próprio administrador ou conflitos após atualizações.

Por isso, esse método é mais indicado para quem já tem familiaridade com WordPress e algum conhecimento técnico.

Um exemplo funcional seria:

add_action('init', function () {

    $novo_login = 'nomenovodoacesso'; // altere depois para o caminho desejado

    // Bloqueia acesso direto ao wp-login.php
    if (strpos($_SERVER['REQUEST_URI'], 'wp-login.php') !== false) {
        wp_redirect(home_url());
        exit;
    }

    // Cria novo endpoint de login
    if (trim($_SERVER['REQUEST_URI'], '/') === $novo_login) {
        require_once ABSPATH . 'wp-login.php';
        exit;
    }
});

Nesse caso, o acesso ao painel administrativo passa a ser feito exclusivamente por:

https://seusite.com/nomenovodoacesso

Enquanto isso, qualquer tentativa de acesso direto a /wp-login.php será bloqueada ou redirecionada.

Além disso, recomenda-se sempre manter acesso ao servidor via FTP ou painel da hospedagem. Assim, caso algo dê errado, é possível reverter rapidamente a alteração sem perder o controle administrativo do site.

6. Limite o número de tentativas de login

Por padrão, o WordPress permite tentativas ilimitadas de login.

Assim, esse comportamento facilita ataques do tipo força bruta, nos quais scripts automatizados testam inúmeras combinações de usuário e senha até encontrar credenciais válidas.

Para mitigar esse risco, é altamente recomendável limitar o número de tentativas de login, adicionando uma camada importante de proteção ao painel administrativo.

Uso de plugins

A forma mais simples e segura de implementar essa proteção é por meio de plugins especializados. Entre os mais utilizados e confiáveis, destacam-se:

• Login LockDown
  Plugin leve e direto ao ponto.
• Limit Login Attempts Reloaded
  Um dos plugins mais populares para essa função.
• WPS Limit Login
  Alternativa simples e eficiente, com foco exclusivo no bloqueio de tentativas excessivas. Indicado para projetos menores ou quando se deseja manter o ambiente mais enxuto.
• Wordfence Security
  Embora seja uma solução de segurança mais ampla (falaremos dele mais a frente), o Wordfence também oferece limitação de tentativas de login, regras avançadas de firewall e bloqueio automático de IPs suspeitos. É indicado quando se busca uma abordagem mais robusta e centralizada de segurança.

Abordagem via functions.php

Também é possível limitar tentativas de login sem plugins, utilizando código personalizado no arquivo functions.php do tema filho (sempre recomendado).

Abaixo está um exemplo simples, que bloqueia o login após um número definido de tentativas falhas por IP:

function limitar_tentativas_login($username) {
    $ip = $_SERVER['REMOTE_ADDR'];
    $key = 'login_attempts_' . md5($ip);
    $attempts = get_transient($key);

    if ($attempts >= 5) {
        wp_die('Muitas tentativas de login. Tente novamente mais tarde.');
    }

    set_transient($key, $attempts + 1, 15 * MINUTE_IN_SECONDS);
}
add_action('wp_login_failed', 'limitar_tentativas_login');

function resetar_tentativas_login($user_login, $user) {
    $ip = $_SERVER['REMOTE_ADDR'];
    $key = 'login_attempts_' . md5($ip);
    delete_transient($key);
}
add_action('wp_login', 'resetar_tentativas_login', 10, 2);

Nesse exemplo:

• O usuário tem até 5 tentativas de login
• Após exceder o limite, o acesso é bloqueado por 15 minutos
• Ao efetuar login com sucesso, o contador é resetado

Lembrando que essa abordagem exige testes cuidadosos, pois não oferece recursos como whitelist de IPs, logs detalhados ou bloqueios progressivos.

Para a maioria dos sites, plugins dedicados continuam sendo a opção mais segura e prática.

7. Use uma conta de Editor no dia a dia

Um erro bastante comum, e frequentemente subestimado, é utilizar uma conta de Administrador para publicar conteúdos rotineiros no WordPress.

Além de conceder privilégios excessivos, esse hábito aumenta a exposição a riscos.

Em muitos temas e plugins, o nome de usuário do autor pode ficar visível no código-fonte da página, em URLs, feeds RSS ou APIs. Isso fornece informações valiosas para ataques direcionados.

Por essa razão, a melhor prática é criar um usuário com perfil de Editor para o uso diário e manter a conta de Administrador restrita apenas a tarefas administrativas, como:

• Instalação e atualização de plugins
• Alterações de temas
• Configurações gerais do site
• Gerenciamento de usuários

Essa separação de funções reduz significativamente o impacto caso a conta usada no dia a dia seja comprometida.

Essa estratégia é especialmente recomendada para sites com postagens frequentes, como blogs, portais de notícias e sites institucionais atualizados regularmente.

Além disso, ela se torna ainda mais importante em sites com muitos usuários, como portais colaborativos, áreas de membros, intranets e projetos com múltiplos autores ou editores.

Quanto maior o número de usuários e o volume de acessos ao painel administrativo, maior também a superfície de ataque.

Portanto, limitar privilégios no uso cotidiano ajuda a manter o controle e a segurança do ambiente.

Em resumo, usar uma conta de Editor no dia a dia não é apenas uma boa prática: é uma forma simples e eficaz de reduzir riscos sem comprometer a produtividade.

8. Backup: uma etapa básica que nunca deve ser ignorada

Quando se fala em segurança no WordPress, o backup costuma ser tratado como algo secundário. No entanto, ele é uma das etapas mais importantes de todo o processo.

Independentemente do nível de proteção adotado, nenhum site está completamente imune a falhas, conflitos, erros humanos ou ataques. Nesses cenários, o backup deixa de ser apenas uma boa prática e passa a ser a única forma de recuperação rápida e segura.

Ter um backup atualizado significa poder restaurar o site em minutos, evitando perda de dados, tempo fora do ar e dores de cabeça desnecessárias.

Lembre-se, limpar um site invadido é uma missão extremamente complicada e nem sempre garantida. A recuperação de uma versão limpa é bem mais fácil e barata.

Pelo menos uma vez: backup completo no computador

Mesmo que o servidor ofereça soluções automatizadas, é altamente recomendável que, ao menos na primeira vez, seja feito um backup completo do site armazenado localmente no computador.

Esse backup inicial deve incluir:

• Todos os arquivos do WordPress (via FTP ou gerenciador de arquivos)
• O banco de dados do site (exportado em formato SQL)

Esse procedimento garante que você tenha uma cópia íntegra do projeto fora do ambiente de hospedagem.

Em situações mais críticas, como falhas no servidor ou problemas de acesso, esse backup local pode ser decisivo para recuperar o site.

Sem falar daqueles que esquecem de pagar o servidor, e dependendo do tempo, acabam perdendo tudo.

Backups automatizados no servidor (quando disponíveis)

Se o servidor foi bem escolhido, o ideal é utilizar backups automatizados diretamente na hospedagem.

Muitos provedores oferecem rotinas programadas de backup, com opções como:

• Backups diários ou semanais
• Retenção de múltiplas versões (importante principalemente para recuperar uma versão que garanta estar limpa)
• Restauração com poucos cliques

Essa automatização reduz falhas humanas e garante consistência. Para sites institucionais simples, um backup semanal pode ser suficiente. Já projetos com atualizações frequentes, lojas virtuais ou portais de conteúdo devem considerar backups diários.

Quando automatizar não é possível, crie uma rotina

Caso o servidor não ofereça backups automáticos confiáveis — ou se essa funcionalidade estiver ausente — é essencial criar uma rotina manual bem definida.

Nesse caso, o mais importante é ter consistência:

• Defina uma periodicidade clara (semanal ou quinzenal)
• Armazene os backups fora do servidor
• Mantenha mais de uma versão disponível
• Documente o processo para não depender da memória

Backup feito de forma esporádica ou sem critério tende a falhar quando mais se precisa dele.

Além disso, vale destacar que o próprio WordPress reforça essa prática. Antes de atualizações importantes, o sistema exibe alertas recomendando a realização de backups do site e banco de dados.

Isso acontece porque atualizações podem alterar estruturas internas, dados e arquivos críticos. Caso algo dê errado, o backup é a única forma segura de reversão.

Portanto, se até o WordPress alerta para esse cuidado, ignorá-lo é assumir um risco desnecessário.

Em segurança, prevenir é essencial. Mas estar preparado para recuperar o site é o que realmente faz a diferença.

9. Uso obrigatório de SSL (HTTPS)

O SSL (Secure Sockets Layer) é a tecnologia que criptografa a comunicação entre o servidor e o navegador do visitante, impedindo que dados sejam interceptados ou manipulados durante a navegação.

O uso de HTTPS é obrigatório hoje em dia, especialmente em sites WordPress com:

• formulários de contato,
• áreas de login,
• e-commerce,
• ou qualquer tipo de troca de dados sensíveis.

Além da segurança, o SSL também:

• aumenta a confiança do usuário;
• evita alertas de “site não seguro” nos navegadores;
• contribui positivamente para o SEO, já que o HTTPS é um fator de ranqueamento.

Atualmente, a maioria dos servidores já oferece certificados SSL gratuitos, como o Let’s Encrypt, que podem ser ativados facilmente no painel de hospedagem.

Caso necessário, também é possível utilizar certificados pagos, adquiridos junto a autoridades certificadoras, ou opções gratuitas alternativas, como a WoSign.

Importante: após ativar o SSL, é fundamental forçar o redirecionamento de HTTP para HTTPS e garantir que todo o conteúdo do site (imagens, scripts e estilos) seja carregado de forma segura, evitando problemas de conteúdo misto.

Como em outras práticas de segurança, o SSL deve fazer parte de um monitoramento contínuo, garantindo que o certificado esteja sempre válido e corretamente configurado.

O Básico da Segurança

Como vimos ao longo desta segunda parte, a segurança no WordPress não depende, necessariamente, de soluções complexas ou caras.

Na prática, boa parte das invasões ocorre por falhas básicas, configurações padrão mantidas por descuido ou decisões equivocadas tomadas ainda no início do projeto.

Ao escolher bem o servidor, realizar uma instalação mais controlada, alterar padrões previsíveis, adotar senhas fortes, limitar tentativas de login e separar corretamente os níveis de acesso dos usuários, você já elimina a maioria das brechas exploradas por ataques automatizados.

Essas medidas não tornam um site “invencível”, mas reduzem drasticamente a superfície de ataque e aumentam o nível de esforço necessário para qualquer tentativa de invasão.

Como consequência, sites que seguem esses fundamentos tendem a ficar fora do radar da maior parte dos ataques oportunistas.

Na Parte 3, avançaremos para um próximo nível de segurança.

Segurança não é um evento isolado. É um processo contínuo. E tudo começa no básico.

Se este texto está te ajudando ou tem alguma dúvida, pode falar conosco.