En bref : pour les droits des fichiers sur le serveur web, un principe s'applique : l'utilisateur sous lequel PHP s'exécute peut lire son propre code, mais pas le modifier. Seuls les dossiers d'upload, de cache et temporaires reçoivent des droits d'écriture, et aucun PHP n'y est exécuté. Des droits comme 777 n'ont pas leur place sur un serveur de production.
Pourquoi les droits des fichiers font la différence après une intrusion
Lorsque des attaquants exécutent du code sur un serveur via une faille, ce code s'exécute avec les droits du processus PHP. Ce que cet utilisateur peut faire, l'attaquant peut le faire aussi. C'est précisément ici que se décide si une intrusion devient une porte dérobée durable.
Avec PHP2Shell, ce scénario est devenu très concret en octobre 2026. Les failles CVE-2026-109618 et CVE-2026-109619 permettent l'exécution de code malveillant sans authentification. Elles sont corrigées depuis le 21 octobre 2026 dans PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. De bons droits de fichiers n'empêchent pas une attaque, mais ils empêchent le code introduit de réécrire durablement votre application.
Dans de nombreuses installations, tout le code appartient à l'utilisateur du serveur web afin que les mises à jour fonctionnent d'un clic. C'est pratique, mais c'est précisément la configuration que recherchent les attaquants.
Le principe de base : séparer le propriétaire et l'utilisateur d'exécution
Une répartition en deux rôles est judicieuse. Un propriétaire, par exemple un utilisateur de déploiement, possède les fichiers et installe les mises à jour. Le processus PHP tourne sous un autre utilisateur et n'a qu'un droit de lecture, via le groupe.
| Domaine | Propriétaire : groupe | Droits des fichiers | Droits des dossiers |
|---|---|---|---|
| Code du programme | deploy : seite1 | 640 | 750 |
| Configuration avec mots de passe | deploy : seite1 | 640 | – |
| Uploads, cache, temp | seite1 : seite1 | 640 | 750 |
| Journaux | root ou seite1 | 640 | 750 |
Le serveur web lui-même, par exemple Nginx, n'a besoin avec PHP-FPM que d'un accès en lecture aux fichiers statiques comme les images et le CSS. Vous l'obtenez via le groupe ou une règle d'accès ciblée. Qui exploite plusieurs sites attribue à chacun son propre utilisateur d'exécution ; la manière dont cela s'articule avec les pools figure dans le guide open_basedir et isolation par site web.
Contrôler les droits des fichiers sur le serveur web
Avant de modifier quoi que ce soit, faites-vous une vue d'ensemble. Les commandes suivantes ne modifient rien.
# Sous quel utilisateur les processus PHP tournent-ils ?
ps -eo user,cmd | grep -E "[p]hp-fpm|[a]pache2|[h]ttpd" | sort | uniq -c
# Fichiers et dossiers accessibles en écriture pour tous
find /var/www -perm -o+w -ls
# Fichiers appartenant à l'utilisateur du serveur web (exemple www-data)
find /var/www -user www-data -type f -name "*.php" | head -50
# Droits des fichiers de configuration
ls -la /var/www/*/wp-config.php /var/www/*/.env 2>/dev/null
Les entrées accessibles en écriture pour tous sont presque toujours une erreur. Les fichiers PHP appartenant à l'utilisateur d'exécution montrent que celui-ci peut modifier son code. Sont en outre suspects les fichiers isolés dont le propriétaire ou les droits diffèrent de ceux des fichiers voisins. Cela peut indiquer des fichiers introduits, comme décrit dans le guide Détecter et supprimer les webshells.
Corriger les droits : pas à pas
Ne modifiez les droits qu'après une sauvegarde et, si possible, d'abord sur un environnement de test. En cas de soupçon d'intrusion, préservez au préalable les traces, car le propriétaire et les horodatages sont alors des éléments de preuve.
SITE=/var/www/seite1
# Propriétaire : utilisateur de déploiement, groupe : utilisateur d'exécution
sudo chown -R deploy:seite1 "$SITE"
# Dossiers 750, fichiers 640
sudo find "$SITE" -type d -exec chmod 750 {} +
sudo find "$SITE" -type f -exec chmod 640 {} +
# PHP ne peut écrire que dans ces dossiers (adapter les chemins à l'application)
sudo chown -R seite1:seite1 "$SITE/public/uploads" "$SITE/var/cache"
Vérifiez ensuite le site en entier : page d'accueil, connexion, formulaires, upload d'images, caches. Les dossiers dans lesquels une application doit écrire figurent dans la configuration requise de l'éditeur, sur sa page officielle.
Un chmod -R 777 pour résoudre rapidement un problème ouvre le serveur à tout utilisateur local et à tout processus introduit. Corrigez plutôt le propriétaire et le groupe.
Empêcher l'exécution de PHP dans les dossiers accessibles en écriture
Les droits d'écriture sont deux fois moins dangereux si aucun code ne peut s'y exécuter. Bloquez l'exécution de PHP dans les dossiers d'upload et de cache au niveau du serveur web. Pour Apache, dans la configuration du VirtualHost :
<Directory "/var/www/seite1/public/uploads">
<FilesMatch "\.(php|phtml|phar)$">
Require all denied
</FilesMatch>
</Directory>
Pour Nginx, un bloc location qui refuse les requêtes vers des fichiers PHP dans ces dossiers suffit. La règle doit figurer dans la configuration du serveur, pas dans un .htaccess du dossier d'upload qu'un attaquant disposant de droits d'écriture pourrait de nouveau modifier.
En complément, il vaut la peine de regarder le umask de l'utilisateur de déploiement, afin que les nouveaux fichiers ne soient pas créés automatiquement avec des droits trop ouverts. Une valeur de 027 donne 640 pour les fichiers et 750 pour les dossiers. Sur vos propres serveurs, cette responsabilité vous incombe entièrement ; ce qui en fait partie par ailleurs est décrit dans Sécuriser soi-même serveurs dédiés et vServers.
Cas particuliers : panneaux d'hébergement, hébergement mutualisé et déploiements
Tous les serveurs ne se configurent pas selon le manuel. Les panneaux d'hébergement comme Plesk ou cPanel créent leurs propres utilisateurs et droits et les réinitialisent lors de certaines actions. Modifiez les droits de préférence via les fonctions du panneau ou vérifiez après les mises à jour du panneau que vos réglages s'appliquent toujours.
Sur un hébergement mutualisé, vous n'avez généralement qu'un seul utilisateur pour tout. Une séparation du propriétaire et de l'utilisateur d'exécution n'est alors pas possible. D'autant plus importants sont des droits stricts sur les fichiers de configuration, l'absence de droits 777 et la désactivation de l'exécution de PHP dans les dossiers d'upload, pour autant que l'hébergeur le permette.
Qui travaille avec des déploiements automatiques devrait définir les droits dans le script de déploiement lui-même. Sinon, chaque nouvelle version rétablit l'ancien état, trop ouvert. Un bref contrôle à la fin du déploiement, par exemple avec la commande ci-dessus pour les fichiers accessibles en écriture, intercepte de tels retours en arrière de façon fiable et s'intègre sans grand effort dans n'importe quel pipeline.
Comment PHP SOS aide-t-il concrètement ?
- Nous recensons les propriétaires, les droits et l'utilisateur d'exécution de tous les sites sur le serveur.
- Nous définissons un concept de droits adapté à votre application et à votre mode de mise à jour.
- Nous mettons en œuvre les droits et les blocages d'exécution, puis testons entièrement le site.
- Nous documentons le concept afin que les déploiements et les mises à jour ne l'affaiblissent pas de nouveau.
La prestation Renforcement de serveur pour serveurs web PHP décrit comment cela s'inscrit dans une sécurisation durable.
Questions fréquentes
Les droits 777 sont-ils jamais acceptables ?
Sur un serveur de production, pratiquement jamais. Avec 777, tout utilisateur du système peut créer et modifier des fichiers. Si une application ne fonctionne pas sans 777, c'est le plus souvent le propriétaire qui est mal défini, pas les droits qui sont trop stricts.
Pourquoi le serveur web ne doit-il pas pouvoir modifier ses propres fichiers ?
Parce que le code introduit s'exécute avec les droits du serveur web. Si le serveur web peut écrire des fichiers PHP, un attaquant peut manipuler des scripts existants ou créer de nouvelles portes dérobées. Si l'on sépare le propriétaire et l'utilisateur d'exécution, le code reste protégé en écriture.
Comment mettre à jour un CMS si le serveur web ne peut pas écrire ?
Les mises à jour passent alors par le propriétaire, par exemple avec WP-CLI, Composer ou un déploiement, et non par le bouton de mise à jour de l'administration. C'est un peu plus contraignant, mais du code introduit ne peut alors pas modifier les fichiers du programme.
Quels droits faut-il pour le fichier de configuration contenant le mot de passe de la base de données ?
Le moins possible : lisible pour l'utilisateur PHP, pour personne d'autre. On utilise en général 640 avec le groupe approprié, ou 400 si l'utilisateur PHP est lui-même propriétaire.