Permissões recomendadas no WordPress: 755, 644 e wp-config.php

Este artigo é uma edição localizada do original em japonês. Ler o original em japonês

No WordPress, o básico é deixar as pastas com permissão 755 e os arquivos com 644. O wp-config.php, que contém os dados de conexão com o banco de dados, deve ser legível por ainda menos pessoas. Além dos números, confirme também quem é o proprietário dos arquivos e com qual usuário o PHP é executado: assim você evita tanto o vazamento de informações quanto o problema de "não consegue atualizar". Os valores recomendados neste artigo foram conferidos, em novembro de 2026, no guia oficial do WordPress "Reforçar a segurança do WordPress" (Hardening WordPress).

Como ler os números das permissões

A permissão é expressa para três grupos, "proprietário, grupo e outros", e cada um é a soma de leitura (4), escrita (2) e execução (1).

A "execução (x)" de uma pasta é a permissão de entrar nela. Se você tirar o x de uma pasta, os arquivos dentro dela deixam de poder ser lidos.

Valores recomendados para o WordPress

Não é necessário usar 777 (qualquer um pode escrever). Em servidores compartilhados, outros usuários do mesmo servidor poderiam alterar seus arquivos.

Alguns servidores de hospedagem definem seus próprios valores recomendados (porque a forma de executar o PHP varia de servidor para servidor). Se o manual da sua hospedagem indicar valores, siga-os.

Como pensar no proprietário dos arquivos

Segundo a explicação oficial, os arquivos devem pertencer à sua própria conta de usuário e ser graváveis por você. Somente os arquivos em que o WordPress precisa escrever (uploads, o tema quando você usa o Editor de arquivos de tema etc.) devem ter proprietário ou grupo ajustado para que o usuário que executa o servidor web (PHP) possa escrever neles.

Se você passar tudo para o usuário do servidor web, como em chown -R www-data:www-data, o PHP poderá alterar todos os arquivos. Isso amplia o estrago quando uma vulnerabilidade de plugin é explorada, então verifique primeiro a situação atual antes de decidir.

Quando uma atualização de plugin ou do núcleo pede "dados de conexão (host, usuário e senha de FTP)", a causa costuma ser justamente essa diferença de proprietário. O WordPress só escolhe o método de alterar os arquivos diretamente quando o proprietário dos arquivos criados pelo PHP é o mesmo dos arquivos do WordPress. Se forem diferentes, ele pede a atualização via FTP. Em vez de ampliar a permissão para 777, corrija ajustando o proprietário.

Verifique a configuração atual

Entre por SSH na pasta do WordPress e use os comandos abaixo para ver os valores e o proprietário. Adapte os caminhos ao seu ambiente.

cd /var/www/html

# Valor, proprietário e grupo do wp-config.php
stat -c '%a %U:%G %n' wp-config.php

# Procura arquivos e pastas em que outros usuários podem escrever
find . -perm -o=w ! -type l

# Procura arquivos PHP dentro do uploads (normalmente não existem)
find wp-content/uploads -type f -name '*.php'

O usuário com o qual o PHP é executado quando alguém acessa pela web deve ser confirmado na configuração do servidor (por exemplo, o user do pool do PHP-FPM) ou no manual da hospedagem. Ele não é necessariamente o mesmo usuário com o qual você entrou por SSH.

Se houver na pasta uploads um arquivo PHP desconhecido, suspeite de adulteração e, antes de apagá-lo, registre a data e o conteúdo do arquivo.

Corrija as permissões em lote

Execute na pasta do WordPress. Faça um backup antes de executar.

cd /var/www/html

# Padroniza as pastas em 755 e os arquivos em 644
find . -type d -exec chmod 755 {} +
find . -type f -exec chmod 644 {} +

# Restringe o wp-config.php (exemplo para ambiente em que o PHP roda como proprietário do arquivo)
chmod 600 wp-config.php

Escolha o valor do wp-config.php conforme o seu ambiente, assim:

• O PHP roda com o mesmo usuário proprietário do arquivo (a maioria das hospedagens compartilhadas, PHP-FPM por usuário): 600 ou 400
• O proprietário é a sua própria conta e o servidor web lê pelo grupo: use 640 ou 440 e coloque como grupo o grupo do servidor web

# Exemplo: proprietário é você, grupo é o do servidor web (www-data) e permissão 640
sudo chgrp www-data wp-config.php
chmod 640 wp-config.php

Depois de configurar, abra o site e o painel e confirme que a exibição e o login funcionam. Se aparecer uma tela em branco ou um erro, o PHP não está conseguindo ler o wp-config.php. Volte o valor para 644 e reveja o proprietário e o grupo.

Com 400 ou 440, os plugins que gravam no wp-config.php (como os que escrevem a configuração de cache) falham. Só permita a escrita temporariamente ao configurar esses plugins.

Impeça que o wp-config.php seja lido pela web

Se o PHP está funcionando normalmente, acessar o wp-config.php pelo navegador não mostra o conteúdo. Para evitar que o código-fonte seja exibido caso o PHP pare de funcionar, por exemplo, negue o acesso também no servidor web. No Apache 2.4, escreva o seguinte no .htaccess da pasta em que o WordPress está instalado (o antigo Order Deny,Allow / Deny from all é a sintaxe do Apache 2.2).

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

O passo a passo detalhado está em "Como negar o acesso ao wp-config.php".

O próprio .htaccess já tem o acesso negado pela configuração padrão do Apache (<Files ".ht*"> do httpd.conf).

Segundo a explicação oficial, também é possível mover o wp-config.php para uma pasta acima daquela em que o WordPress está instalado. O WordPress procura na pasta acima se não houver um wp-config.php na mesma pasta. Mas o próprio guia oficial menciona opiniões de que o efeito é pequeno e que, se feito de forma errada, pode até ficar mais perigoso. Se for mover, confirme que a pasta acima não é uma pasta pública.

Não execute PHP na pasta uploads

A pasta uploads é onde o WordPress grava arquivos, e por isso é um local em que os invasores tendem a plantar arquivos. Se o PHP não puder ser executado ali, mesmo que um arquivo seja colocado, ele não funciona.

No Apache 2.4, crie o wp-content/uploads/.htaccess e escreva o seguinte.

<FilesMatch "\.(php|phtml|phar)$">
    Require all denied
</FilesMatch>

Para usar Require no .htaccess, é preciso que o AllowOverride do servidor permita isso. Se não permitir, ocorre erro 500 ou a configuração é ignorada. Depois de escrever, abra uma URL de PHP inexistente como https://example.com/wp-content/uploads/test.php e confirme que retorna 403 (se continuar 404, a configuração não está valendo).

No Nginx, dentro do bloco server, coloque o seguinte antes do location ~ \.php$ que processa o PHP. Isso porque os location com expressão regular são avaliados de cima para baixo e vale o primeiro que corresponder.

location ~* ^/wp-content/uploads/.*\.(php|phtml|phar)$ {
    deny all;
}

Depois de alterar a configuração, verifique a sintaxe com nginx -t e só então recarregue.

Observe ainda que, por padrão, o envio de mídia do WordPress não aceita arquivos que não sejam dos tipos permitidos (imagens, PDF etc.). Normalmente não é possível enviar um arquivo PHP como mídia pelo painel.

Pontos de atenção

• Antes de mudar as permissões, faça backup dos arquivos e do banco de dados.
• Ao mudar as permissões com um programa de FTP, alguns servidores não aceitam a alteração em lote. Quando há muitos arquivos, usar o find por SSH é mais rápido e evita esquecimentos.
• Quando uma atualização pedir os dados de conexão FTP, não amplie as permissões: verifique o proprietário. Consulte também "Como corrigir erros de permissão do WordPress".
• Executar periodicamente os comandos de verificação acima (arquivos graváveis por outros usuários e PHP dentro do uploads) ajuda a perceber cedo um desvio de configuração ou uma adulteração.

Dúvidas sobre WordPress? Quem publica este site fica no Japão e responde em japonês. Contato (em japonês)