Proteger wp-config.php no WordPress

O arquivo wp-config.php no diretório raiz de toda instalação WordPress contém as credenciais do banco de dados (host, nome, usuário, senha), as chaves de segurança secretas e os salts, além de constantes de configuração centrais. Se este arquivo cair em mãos erradas, praticamente todo o site fica comprometido. É, portanto, o arquivo individual mais importante a proteger. Este guia mostra quatro medidas de reforço: gerar chaves de segurança novas, definir permissões de arquivo restritivas, bloquear o acesso HTTP direto ao arquivo e adicionar constantes protetoras como DISALLOW_FILE_EDIT. Opcionalmente, o arquivo pode ser movido um nível acima da webroot. Todos os passos podem ser feitos em cerca de 20 minutos via SFTP/SSH e a configuração .htaccess ou nginx.

Passo 1: Regenerar chaves de segurança e salts

O WordPress usa oito cadeias secretas (AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY e os quatro valores _SALT correspondentes) para criptografar cookies de login e nonces. Se esses valores já foram públicos (por exemplo, em um backup acessível na web) ou nunca foram alterados, você deve regenerá-los. O WordPress oferece um gerador oficial para isso:

# Fetch current random values:
https://api.wordpress.org/secret-key/1.1/salt/

Em wp-config.php, substitua o bloco existente pelos valores recém-gerados:

define( 'AUTH_KEY',         'hier-langer-zufallswert' );
define( 'SECURE_AUTH_KEY',  'hier-langer-zufallswert' );
define( 'LOGGED_IN_KEY',    'hier-langer-zufallswert' );
define( 'NONCE_KEY',        'hier-langer-zufallswert' );
define( 'AUTH_SALT',        'hier-langer-zufallswert' );
define( 'SECURE_AUTH_SALT', 'hier-langer-zufallswert' );
define( 'LOGGED_IN_SALT',   'hier-langer-zufallswert' );
define( 'NONCE_SALT',       'hier-langer-zufallswert' );

Após salvar, todos os usuários conectados são desconectados – isso é intencional e uma forma eficaz de invalidar sessões roubadas.

Passo 2: Definir permissões de arquivo

O wp-config.php deve ser legível pelo servidor web, mas inacessível a outros usuários. Recomenda-se 600 (apenas o proprietário pode ler/escrever) ou 640 caso o grupo do servidor web precise de acesso de leitura:

# Only owner reads and writes
chmod 600 wp-config.php

# Alternatively, if the web server group must read
chmod 640 wp-config.php

Nunca defina 777 ou 666 – com isso qualquer usuário no sistema pode ler o arquivo e extrair as credenciais do banco de dados.

Passo 3: Bloquear o acesso HTTP direto

Normalmente o wp-config.php é executado como PHP e não retorna saída. Se o processamento PHP falhar, porém (má configuração, migração de servidor), o conteúdo em texto puro poderia ser servido. Bloqueie o acesso direto adicionalmente no nível do servidor web.

Apache (.htaccess)

<Files wp-config.php>
    Require all denied
</Files>

nginx

location = /wp-config.php {
    deny all;
    return 403;
}

Passo 4: Adicionar constantes de reforço

Em wp-config.php, acima da linha /* That's all, stop editing! */, adicione as seguintes constantes:

// Disable the file editor in the admin area (prevents editing
// theme and plugin code via wp-admin)
define( 'DISALLOW_FILE_EDIT', true );

// Optional: completely prevent installing/updating plugins and
// themes via the dashboard (strictest variant)
// define( 'DISALLOW_FILE_MODS', true );

// Disable debug output in production
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );

// Enforce encrypted connections in the admin area only
define( 'FORCE_SSL_ADMIN', true );

// Limit automatic core updates to security releases
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

DISALLOW_FILE_EDIT é especialmente importante: sem esta constante, um atacante que assume uma conta de administrador pode executar código PHP arbitrário diretamente via Aparência » Editor de temas.

Opcional: Mover o wp-config.php para fora da webroot

O WordPress também procura o wp-config.php um nível de diretório acima da webroot. Se o seu WordPress está em /var/www/html/, você pode mover o arquivo para /var/www/wp-config.php. Assim ele fica fora da área acessível por HTTP.

Atenção: Isso só funciona de forma confiável em instalações clássicas de site único com webroot própria. Em hospedagem compartilhada, onde vários sites dividem o mesmo nível superior, mover pode causar conflitos. Na dúvida, verifique com seu host.

Como verifico se a proteção funciona?

1. Abra https://seu-dominio.com/wp-config.php no navegador. Esperado: uma página vazia (execução PHP) ou 403 Forbidden (acesso bloqueado) – nunca código-fonte PHP legível.
2. Via terminal:

   curl -s -o /dev/null -w "%{http_code}\n" https://your-domain.com/wp-config.php
   # Expected: 403 (with an active block) or 200 with an empty body

3. Verificar as permissões:

   ls -l wp-config.php
   # Expected: -rw------- (600) or -rw-r----- (640)

4. Na área administrativa, confirme que não aparece mais nenhum editor em Aparência e Plugins (efeito de DISALLOW_FILE_EDIT).

Erros comuns

• Permissões muito restritas: Em alguns hosts o PHP não roda como proprietário do arquivo. Nesse caso 600 pode causar um erro 500 – use então 640 ou 644.
• Chaves substituídas sem backup: Faça backup do arquivo antes das alterações. Um erro de digitação nas constantes derruba o site.
• DISALLOW_FILE_MODS cedo demais: Esta constante também bloqueia atualizações normais de plugins/temas pelo painel. Só defina se as atualizações rodarem exclusivamente por deployment/WP-CLI.
• Arquivo movido, mas caminho errado: Ao movê-lo para fora da webroot, não improvise um loader require próprio que exponha um caminho de servidor absoluto.

Perguntas frequentes (FAQ)

Qual permissão de arquivo o wp-config.php deve ter?

Recomenda-se 600 (apenas o proprietário pode ler e escrever). Se no seu host o PHP não roda como proprietário do arquivo mas pelo grupo, use 640. Nunca defina 777 ou 666, pois então qualquer usuário no servidor pode ler as credenciais do banco de dados.

O que acontece se eu alterar as chaves de segurança no wp-config.php?

Todos os usuários conectados são desconectados e precisam entrar novamente. Isso é intencional e uma forma eficaz de invalidar cookies de sessão roubados. O conteúdo do site permanece inalterado. Gere valores novos pelo gerador oficial de chaves secretas do WordPress.

Para que serve a constante DISALLOW_FILE_EDIT?

DISALLOW_FILE_EDIT desativa o editor de temas e plugins na área administrativa do WordPress. Sem esta constante, um atacante que assume uma conta de administrador pode executar código PHP arbitrário diretamente via Aparência » Editor de temas. A constante é, portanto, uma das medidas de reforço mais importantes.

Devo mover o wp-config.php para fora da webroot?

O WordPress também procura o wp-config.php um nível de diretório acima da webroot. Em instalações clássicas de site único com webroot própria, movê-lo aumenta a segurança. Em hospedagem compartilhada, onde vários sites dividem o mesmo nível superior, pode causar conflitos – na dúvida, verifique com seu host.

Como o InspectWP ajuda com o wp-config.php?

Durante o crawl, o InspectWP verifica, entre outras coisas, se arquivos sensíveis como wp-config.php ou um backup wp-config.php.bak estão acessíveis publicamente, se a área administrativa é forçada por HTTPS e se saídas de debug vazam para fora. Os achados correspondentes são marcados como risco de segurança no relatório.