Em resumo: nas permissões de ficheiros do servidor web aplica-se um princípio: o utilizador com que o PHP corre pode ler o próprio código, mas não o alterar. Só as pastas de uploads, cache e temporários recebem permissões de escrita, e aí não se executa PHP. Permissões como 777 não têm lugar num servidor de produção.
Porque é que as permissões de ficheiros fazem a diferença após uma intrusão
Quando os atacantes executam código num servidor através de uma vulnerabilidade, esse código corre com as permissões do processo PHP. O que esse utilizador pode fazer, também o atacante pode. É precisamente aqui que se decide se uma intrusão se torna numa backdoor persistente.
Com o PHP2Shell, este cenário tornou-se muito concreto em outubro de 2026. As vulnerabilidades CVE-2026-109618 e CVE-2026-109619 permitem a execução de código malicioso sem autenticação. Estão corrigidas desde 21/10/2026 no PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Boas permissões de ficheiros não impedem um ataque, mas impedem que o código introduzido reescreva a sua aplicação de forma duradoura.
Em muitas instalações, todo o código pertence ao utilizador do servidor web, para que as atualizações funcionem com um clique. É cómodo, mas é exatamente a constelação que os atacantes procuram.
O princípio básico: separar o proprietário e o utilizador de execução
Faz sentido uma divisão em dois papéis. Um proprietário, por exemplo um utilizador de deploy, possui os ficheiros e instala as atualizações. O processo PHP corre com outro utilizador e só tem permissão de leitura através do grupo.
| Área | Proprietário : grupo | Permissões de ficheiros | Permissões de pastas |
|---|---|---|---|
| Código do programa | deploy : seite1 | 640 | 750 |
| Configuração com palavras-passe | deploy : seite1 | 640 | – |
| Uploads, cache, temporários | seite1 : seite1 | 640 | 750 |
| Registos | root ou seite1 | 640 | 750 |
O próprio servidor web, por exemplo o Nginx, só precisa, com o PHP-FPM, de acesso de leitura a ficheiros estáticos como imagens e CSS. Obtém-no através do grupo ou de uma regra de acesso específica. Quem opera vários sites dá a cada um um utilizador de execução próprio; como isto se articula com os pools, está no guia open_basedir e isolamento por site.
Verificar as permissões de ficheiros no servidor web
Antes de alterar seja o que for, obtenha uma visão geral. Os comandos seguintes não alteram nada.
# Com que utilizador correm os processos PHP?
ps -eo user,cmd | grep -E "[p]hp-fpm|[a]pache2|[h]ttpd" | sort | uniq -c
# Ficheiros e pastas graváveis por todos
find /var/www -perm -o+w -ls
# Ficheiros que pertencem ao utilizador do servidor web (exemplo www-data)
find /var/www -user www-data -type f -name "*.php" | head -50
# Permissões dos ficheiros de configuração
ls -la /var/www/*/wp-config.php /var/www/*/.env 2>/dev/null
Entradas graváveis por todos são quase sempre um erro. Ficheiros PHP que pertencem ao utilizador de execução mostram que este pode alterar o seu código. Chamam ainda a atenção ficheiros isolados cujo proprietário ou permissões divergem dos ficheiros vizinhos. Isso pode ser indício de ficheiros introduzidos, como descrito no guia Detetar e remover webshells.
Corrigir as permissões: passo a passo
Altere as permissões apenas depois de uma cópia de segurança e, se possível, primeiro num ambiente de teste. Se houver suspeita de intrusão, guarde antes os vestígios, porque o proprietário e as marcas temporais são então meios de prova.
SITE=/var/www/seite1
# Proprietário: utilizador de deploy, grupo: utilizador de execução
sudo chown -R deploy:seite1 "$SITE"
# Pastas 750, ficheiros 640
sudo find "$SITE" -type d -exec chmod 750 {} +
sudo find "$SITE" -type f -exec chmod 640 {} +
# O PHP só pode escrever nestas pastas (adapte os caminhos à aplicação)
sudo chown -R seite1:seite1 "$SITE/public/uploads" "$SITE/var/cache"
Depois, verifique o site por completo: página inicial, login, formulários, upload de imagens, caches. As pastas em que uma aplicação tem de escrever constam dos requisitos de sistema do fabricante na sua página oficial.
Um chmod -R 777 para resolver rapidamente um problema abre o servidor a qualquer utilizador local e a qualquer processo introduzido. Corrija antes o proprietário e o grupo.
Impedir a execução de PHP em pastas graváveis
As permissões de escrita são só metade tão perigosas se ali não puder correr código. Bloqueie a execução de PHP nas pastas de uploads e de cache ao nível do servidor web. Para o Apache, na configuração do VirtualHost:
<Directory "/var/www/seite1/public/uploads">
<FilesMatch "\.(php|phtml|phar)$">
Require all denied
</FilesMatch>
</Directory>
Para o Nginx basta um bloco location que recuse pedidos a ficheiros PHP nessas pastas. A regra pertence à configuração do servidor, não a um .htaccess na pasta de uploads, que um atacante com permissões de escrita poderia voltar a alterar.
Em complemento, vale a pena olhar para a umask do utilizador de deploy, para que os novos ficheiros não sejam criados automaticamente demasiado abertos. Um valor de 027 resulta em 640 para ficheiros e 750 para pastas. Em servidores próprios, esta responsabilidade é inteiramente sua; o que mais lhe pertence, descreve-o Proteger você mesmo servidores root e vServers.
Casos especiais: painéis de alojamento, alojamento partilhado e deployments
Nem todo o servidor se deixa configurar como nos manuais. Painéis de alojamento como o Plesk ou o cPanel criam utilizadores e permissões próprios e repõem-nos em algumas ações. Altere as permissões aí, se possível, através das funções do painel ou verifique, após atualizações do painel, se as suas definições ainda valem.
No alojamento partilhado costuma ter apenas um utilizador para tudo. Uma separação entre proprietário e utilizador de execução não é então possível. Tanto mais importantes são permissões restritas nos ficheiros de configuração, nenhuma permissão 777 e a desativação da execução de PHP nas pastas de uploads, na medida em que o fornecedor o permita.
Quem trabalha com deployments automáticos deve definir as permissões no próprio script de deployment. Caso contrário, cada nova versão repõe o estado antigo, demasiado aberto. Uma breve verificação no fim do deployment, por exemplo com o comando acima para ficheiros graváveis, apanha de forma fiável tais retrocessos e pode ser integrada sem grande esforço em qualquer pipeline.
Como ajuda concretamente a PHP SOS?
- Registamos proprietários, permissões e utilizadores de execução de todos os sites do servidor.
- Definimos um conceito de permissões adequado à sua aplicação e ao seu processo de atualização.
- Aplicamos permissões e bloqueios de execução e testamos depois o site por completo.
- Documentamos o conceito, para que deployments e atualizações não o voltem a enfraquecer.
Como isto se integra numa proteção duradoura, descreve-o o serviço Reforço de segurança de servidores PHP.
Perguntas frequentes
As permissões 777 estão alguma vez corretas?
Num servidor de produção, praticamente nunca. Com 777, qualquer utilizador do sistema pode criar e alterar ficheiros. Se uma aplicação não funciona sem 777, o proprietário está geralmente mal definido, não as permissões demasiado restritas.
Porque é que o servidor web não deve poder alterar os seus próprios ficheiros?
Porque o código introduzido corre com as permissões do servidor web. Se o servidor web puder escrever ficheiros PHP, um atacante pode manipular scripts existentes ou criar novas backdoors. Se se separarem o proprietário e o utilizador de execução, o código fica protegido contra escrita.
Como atualizo um CMS se o servidor web não pode escrever?
As atualizações passam então pelo proprietário, por exemplo com WP-CLI, Composer ou deployment, e não pelo botão de atualização do backend. É um pouco mais trabalhoso, mas em contrapartida o código introduzido não consegue alterar os ficheiros do programa.
Que permissões precisa o ficheiro de configuração com a palavra-passe da base de dados?
O mínimo possível: legível para o utilizador PHP e para mais ninguém. O habitual é 640 com o grupo adequado ou 400, se o próprio utilizador PHP for o proprietário.