Droits des fichiers : chmod 644, 755, 600 et pourquoi jamais 777

Sur un hébergement mutualisé, mettez les dossiers en 755, les fichiers en 644 et wp-config.php en 600 ou 640. Tous les fichiers doivent appartenir à votre utilisateur d’hébergement : le propriétaire compte autant que les chiffres. Vous n’avez jamais besoin de 777 : sur notre banc d’essai, un fichier PHP déposé par un autre utilisateur du serveur dans un dossier en 777 s’est exécuté avec les droits du propriétaire du site et pouvait réécrire n’importe quel fichier du site.

Lire les droits : trois chiffres, trois classes

Chaque fichier a un propriétaire, un groupe et des droits distincts pour trois classes : le propriétaire, le groupe et tous les autres. La lecture vaut 4, l’écriture 2, l’exécution 1, et chaque chiffre en est la somme : 7 signifie rwx, 6 rw, 5 r et x, 4 lecture seule, 0 rien du tout. Le premier chiffre concerne le propriétaire, le deuxième le groupe, le troisième tous les autres. Cette commande affiche les modes et les propriétaires sous forme numérique :

$ stat -c '%a %U:%G %n' wp-config.php index.php wp-content
600 cw8site:cw8site wp-config.php
644 cw8site:cw8site index.php
755 cw8site:cw8site wp-content

Sur un dossier, les mêmes lettres ont un autre sens : r liste les fichiers, w crée, renomme et supprime des fichiers à l’intérieur, x permet d’entrer dans le dossier et d’ouvrir les fichiers dont on connaît le nom. C’est pourquoi les dossiers ont besoin de x et les fichiers ordinaires du site non : un script PHP n’est pas lancé comme un programme, l’interpréteur se contente de le lire. Un détail de plus qui ressort des tests : quiconque a le droit d’écriture sur un dossier peut y supprimer ou renommer des fichiers, même ceux qui ne lui appartiennent pas.

Tableau des droits : qui peut faire quoi, et quand l’utiliser

Testé sur un banc où les fichiers appartiennent à l’utilisateur du site et où nginx et Apache tournent en tant que www-data. Pour le serveur web, vos fichiers relèvent de « tous les autres » : c’est donc le troisième chiffre qui décide s’il peut servir une image ou une feuille de style.

Sous quel utilisateur tourne PHP : le propriétaire ou www-data

Les mêmes modes se comportent différemment selon l’utilisateur sous lequel PHP tourne. Dans la plupart des panneaux de contrôle, chaque pool PHP-FPM tourne en tant que propriétaire du domaine : la directive user du pool désigne le compte du site, avec www-data comme groupe du socket. Les configurations plus anciennes et les serveurs gérés soi-même font souvent tourner PHP en tant que www-data, comme le serveur web.

Un tout petit fichier vous indique votre cas. Placez-le à la racine du site, ouvrez-le dans un navigateur, puis supprimez-le aussitôt :

<?php
echo posix_getpwuid(posix_geteuid())['name'], "\n";
echo is_writable(__DIR__ . '/wp-content') ? "wp-content writable\n" : "wp-content NOT writable\n";

Avec des droits identiques sur le banc (dossiers 755, fichiers 644, propriétaire : l’utilisateur du site), voici ce que nous avons obtenu :

À retenir : quand PHP tourne en tant que propriétaire, WordPress écrit dans ses dossiers sans aucun 777, et 755 plus 644 suffisent. Le revers : un script malveillant qui atterrit sur le site obtient lui aussi les droits du propriétaire. La priorité n’est donc pas d’assouplir les droits, mais de faire en sorte qu’un tel script ne s’exécute jamais.

Ce que sert le serveur web : chmod 600 sur une image ou sur un fichier PHP

nginx et Apache tournent en tant que www-data. Ils lisent eux-mêmes les fichiers statiques et confient les fichiers PHP à PHP-FPM, qui les ouvre sous son propre utilisateur. Cela explique une différence qu’on prend facilement pour un bug :

Apache consigne une telle image sous la forme AH00132: file permissions deny server access, nginx sous la forme open() ... failed (13: Permission denied), et PHP-FPM écrit Unable to open primary script ... (Permission denied). Si un fichier doit vraiment être en 640 et que le serveur web doit le lire, son groupe doit être www-data : avec ce groupe, l’image était servie en 200. Les autres causes de ce code sont traitées dans notre guide sur l’erreur 403 Forbidden. Si seules les images ont disparu après un déménagement du site alors que les pages s’ouvrent encore, vérifiez les modes dans wp-content/uploads : un outil d’archivage ou un client FTP a pu enregistrer les fichiers en 600.

Pourquoi chmod 777 est dangereux : trois tests sur le banc

777 permet à n’importe quel processus et à n’importe quel utilisateur du serveur de créer, supprimer et remplacer des fichiers. Sur le banc, cela a donné ceci :

1. Le fichier d’un autre s’exécute en votre nom. Un autre utilisateur du serveur a déposé un fichier PHP dans un wp-content en 777. Nous l’avons ouvert dans un navigateur et le script s’est exécuté en tant que propriétaire du site : il pouvait lire wp-config.php et écrire dans index.php. Avec 755, le même utilisateur a obtenu « Permission denied ».
2. La protection peut tout simplement être retirée. La règle qui bloquait PHP dans uploads se trouvait dans un fichier .htaccess en mode 644. Mais le dossier était en 777 : l’autre utilisateur a renommé le .htaccess, et le web shell de test a de nouveau répondu 200. Le mode du fichier lui-même n’a servi à rien, car c’est le dossier qui contrôle la suppression et le renommage.
3. 777 ouvre la porte à un script d’envoi vulnérable. Nous avons volontairement installé un script d’envoi sans contrôle de l’extension. Avec PHP en www-data et uploads en 755, shell.php n’a pas été enregistré : move_uploaded_file(): Unable to move. Après chmod 777, il a été enregistré puis exécuté.

Deux effets secondaires de plus. WordPress fixe le mode des nouveaux médias d’après le mode du dossier : dans un dossier en 777, les envois sortaient donc en 666, modifiables par tout le monde. Et les fichiers créés par www-data ne peuvent plus être modifiés par le propriétaire du site : chmod et chown ont renvoyé « Operation not permitted », et seul un administrateur du serveur peut les corriger. Sur un hébergement aux comptes isolés, les voisins n’atteignent généralement pas vos dossiers, mais 777 supprime la dernière ligne de défense.

Bloquer l’exécution de PHP dans uploads

Cette règle protège quels que soient les droits : même si un fichier malveillant arrive dans uploads, le serveur ne l’exécutera pas. Pour Apache, et pour nginx devant Apache, placez ce fichier .htaccess dans wp-content/uploads :

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

Pour nginx sans Apache, ajoutez ceci dans le bloc server au-dessus de la location PHP, car les locations en expression régulière sont vérifiées dans l’ordre :

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

Sur le banc, les deux règles ont renvoyé 403 pour shell.php, tandis que les images du même dossier étaient toujours servies en 200. D’autres règles prêtes à l’emploi figurent dans nos exemples de fichier .htaccess.

wp-config.php : 600, 640 ou 400

wp-config.php contient le mot de passe de la base de données : la vraie question est donc de savoir qui d’autre peut le lire. En 644, un autre utilisateur du serveur a lu la ligne DB_PASSWORD sur le banc sans le moindre effort.

La documentation de WordPress recommande 440 ou 400 (File Permissions, vérifié le 10 novembre 2026). Si PHP tourne sous votre utilisateur, utilisez 600 : le site fonctionne et les voisins ne peuvent pas lire le fichier. 400 empêche en plus les scripts de le modifier, mais certaines extensions de cache et de sécurité écrivent elles-mêmes des constantes dans wp-config.php et signaleront alors une erreur. Si PHP tourne en tant que www-data, utilisez 640 ou 440 avec le groupe www-data. Sans root, vous ne pouvez pas attribuer à un fichier un groupe dont vous n’êtes pas membre : adressez-vous au support. En 600 sans ce groupe, le site renvoyait une page 500 blanche, et le journal PHP affichait Failed to open stream: Permission denied in .../wp-load.php. Notre article sur l’erreur 500 Internal Server Error explique comment lire ce type de réponse.

umask : pourquoi les nouveaux fichiers sont en 644

Le mode d’un nouveau fichier vient de l’umask, qui retire des bits à la base 666 pour les fichiers et 777 pour les dossiers. Sur le banc :

PHP-FPM hérite de l’umask du processus qui l’a lancé. Quand nous avons démarré le pool avec l’umask 002, les fichiers écrits avec file_put_contents ont obtenu 664 et les dossiers 775. La médiathèque de WordPress s’est comportée autrement : les envois restaient en 644, car WordPress reprend le mode du dossier parent et retire le bit d’exécution. C’est précisément pour cela qu’un seul 777 sur uploads donne 666 à chaque nouveau fichier. En SSH, umask affiche votre masque et umask 022 rétablit la valeur habituelle pour la session.

« Could not create directory » dans WordPress : vérifiez le propriétaire

« Could not create directory » lors de l’installation ou de la mise à jour d’une extension, et « Unable to create directory wp-content/uploads/… Is its parent directory writable by the server? » lors de l’envoi d’un média, signalent presque toujours un mauvais propriétaire, pas des droits trop stricts. Sur le banc, nous avons fait de root le propriétaire de wp-content, comme cela arrive après avoir décompressé une archive en root. PHP tournant en tant que propriétaire du site a immédiatement rencontré les deux erreurs, et WordPress a commencé à demander des identifiants FTP. Après cette commande (user est ici le nom du propriétaire du site)

chown -R user:user wp-content

les envois et les installations d’extensions ont de nouveau fonctionné, sans modifier un seul mode. Si vous installez WordPress à la main, décompressez l’archive sous votre propre utilisateur ; les étapes sont décrites dans notre guide pour installer WordPress sur un hébergement.

Corriger les droits en masse : les commandes find

Connectez-vous à votre hébergement en SSH, placez-vous à la racine du site et lancez :

find . -type d -exec chmod 755 {} +
find . -type f -exec chmod 644 {} +
chmod 600 wp-config.php

Nous avons chronométré trois méthodes sur une arborescence WordPress de 2 777 fichiers et 284 dossiers, en remettant tout en 777 avant chaque passage. Chaque méthode a tourné trois fois en tant que propriétaire du site :

Sur un gros site, un écart d’un facteur cent se remarque : utilisez donc la forme avec le plus. Ces commandes repèrent les fichiers problématiques :

find . -perm -o+w              # writable by anyone
find . -type f -perm /111      # files with the execute bit
find . ! -user $(whoami) -ls   # files owned by another user

Si la dernière commande trouve des fichiers appartenant à www-data ou à root, chmod ne fonctionnera pas sur eux : sur le banc, la correction en masse s’est arrêtée sur un fichier de www-data avec « Operation not permitted ». Sans SSH, modifiez les droits dans le gestionnaire de fichiers du panneau ou dans FileZilla : l’élément « Droits d’accès au fichier » du menu contextuel peut appliquer un mode de façon récursive, aux dossiers seulement ou aux fichiers seulement.

chown : qui peut changer le propriétaire

Seul root peut changer le propriétaire d’un fichier. Sur le banc, la tentative de l’utilisateur du site de céder un fichier à un autre utilisateur s’est soldée par « Operation not permitted ». Sur un hébergement mutualisé, vous n’avez pas root : les fichiers au propriétaire étranger sont corrigés par le support ou par une fonction du panneau. Avec les offres d’hébergement RichHost, les sites se gèrent dans notre propre panneau de contrôle avec assistant IA, et le support travaille de 10h00 à 20h00, heure de Kyiv, et répond en général en moins de 30 minutes.

FAQ

Quels droits faut-il pour WordPress ?

Dossiers 755, fichiers 644, wp-config.php 600. Si PHP tourne en tant que www-data, wp-config.php a besoin de 640 ou 440 avec le groupe www-data. Tous les fichiers doivent appartenir à votre utilisateur.

Pourquoi une image ne s’affiche plus après chmod 600 alors que la page fonctionne ?

Le serveur web lit l’image en tant que www-data, et un fichier en 600 lui est fermé : il répond donc 403. Le fichier PHP est ouvert par PHP-FPM, qui tourne en tant que propriétaire, et 600 suffit pour cela.

Les fichiers PHP ont-ils besoin de 755 ?

Non. L’interpréteur se contente de lire un script PHP et n’a pas besoin du bit d’exécution. 755 sert aux dossiers et aux scripts shell que vous lancez à la main ou via cron.

WordPress demande des identifiants FTP pour installer une extension. Que se passe-t-il ?

PHP ne peut pas écrire dans les fichiers du site, soit parce qu’il tourne sous un autre utilisateur, soit parce que les fichiers ont un autre propriétaire. Sur le banc, les deux cas ont produit exactement cette demande. Corrigez le propriétaire au lieu de passer en 777.

775 et 664 sont-ils sûrs ?

Ils donnent le droit d’écriture au groupe. Si votre utilisateur est le seul membre du groupe, le risque est faible, mais il n’y a aucun avantage non plus : quand PHP tourne en tant que propriétaire, l’écriture pour le groupe est inutile. Restez sur 755 et 644.