Permissions de fichiers
Les permissions de fichiers déterminent qui a le droit de lire, de modifier et d'exécuter chaque fichier et chaque dossier d'un site sur son serveur.
Définition
Les permissions de fichiers déterminent qui a le droit de lire, de modifier et d’exécuter chaque fichier et chaque dossier d’un site sur son serveur. Cette autorisation ne se voit pas depuis WordPress : elle se règle sur l’hébergement, en FTP, en SSH ou dans le gestionnaire de fichiers, et elle décide de ce qu’un intrus pourra faire une fois entré.
Comment se lisent 755 et 644
Trois chiffres, trois publics : le propriétaire, son groupe, tous les autres.
Chaque fichier et chaque répertoire d’un serveur porte trois droits, distribués à trois catégories. Le premier chiffre concerne le compte propriétaire, le deuxième le groupe auquel il appartient, le troisième tout le reste du monde. Dans chacun, 4 vaut la lecture, 2 l’écriture, 1 l’exécution, et on les additionne : 7 donne les trois droits, 6 la lecture et l’écriture, 5 la lecture et l’exécution, 4 la lecture seule.
La valeur 755 sur un répertoire signifie donc que son propriétaire peut y écrire, et que tous les autres peuvent seulement le lire et le traverser. 644 sur un fichier signifie que son propriétaire peut le modifier, et que les autres se contentent de le lire. Sur un dossier, le droit d’exécution n’a rien à voir avec un programme : c’est le droit de le traverser pour atteindre ce qu’il contient, et c’est pourquoi les dossiers sont en 755 quand les fichiers sont en 644.
Ce que les permissions protègent, et ce qu’elles ne protègent pas
Elles ne ferment pas la porte d’entrée, elles réduisent la surface une fois entré.
Une faille d’extension qui permet de téléverser un fichier s’exécute avec les droits du serveur web, c’est-à-dire ceux du compte propriétaire du site. Des permissions correctes ne l’empêchent pas. Elles décident en revanche de la suite : jusqu’où ce code peut écrire, s’il peut modifier le cœur, s’il peut se déposer dans un dossier voisin, et s’il peut atteindre un autre site du même hébergement.
C’est cette dernière question qui rend le 777 dangereux. Sur un hébergement mutualisé, un dossier accessible en écriture par tous est ouvert aux processus des autres comptes de la machine. La compromission d’un site voisin, sur lequel on n’a aucune prise, devient alors une porte d’écriture chez soi. Le catalogue CWE en fait une catégorie de faille à part entière, l’attribution incorrecte de permissions à une ressource critique.
Le 777 « juste le temps de la mise à jour » ne revient jamais en arrière. C’est le conseil le plus fréquent des forums pour débloquer un téléversement, et c’est presque toujours un contournement du vrai problème, qui est un propriétaire de fichier mal réglé. Quand la mise à jour passe, plus rien ne rappelle qu’il faut refermer.
Les trois fichiers qui méritent mieux que la règle
Un fichier de configuration, un fichier de serveur, un dossier d’écriture.
wp-config.php, la configuration
Ce fichier contient les identifiants de la base de données et les clés de sécurité. La documentation WordPress recommande 640 ou 600, c’est-à-dire lisible par son seul propriétaire, quand l’installation le permet.
.htaccess, les règles du serveur
Ce fichier commande les redirections et les refus. WordPress y écrit pour gérer les adresses des pages, il doit donc rester modifiable par le site, sans jamais devenir modifiable par les autres.
wp-content/uploads, les médias
C’est le seul répertoire où WordPress écrit tous les jours. Il ne peut pas être en lecture seule, et c’est pour cela que l’interdiction d’y exécuter du PHP se règle au niveau du serveur, pas des permissions.
Le relevé, à faire une fois
Compter en SSH les fichiers et répertoires accessibles en écriture par tous prend quelques secondes et donne le seul chiffre qui doit être à zéro. Tout le reste est du réglage fin.
Ce qu’un relevé donne sur un site réel
Relevé du 9 septembre 2026, sur la racine d’un site vitrine WordPress d’une trentaine de pages, hébergement mutualisé. 24 704 fichiers et 3 567 dossiers. La base est saine : 3 549 dossiers en 755, 24 497 fichiers en 644, et surtout zéro objet accessible en écriture par tous, ni fichier ni dossier. Les exceptions dessinent toutes le même motif : 17 dossiers et 200 fichiers ouverts en écriture au groupe, et ce sont exactement le thème enfant, ses sous-dossiers, un dossier de préversion et un cache d’images converties. Autrement dit ce qui a été déposé à la main ou écrit par une extension, jamais ce que WordPress a installé lui-même. Le masque de création de la session de dépôt était simplement plus permissif que celui de l’installateur. Sur cet hébergement le compte est son propre groupe, l’écart n’ouvre donc rien à personne, mais il indique où regarder le jour où le compte serait partagé. Dernier point, et le plus instructif : onze fichiers PHP dorment dans le dossier des médias, ce qui déclenche l’alerte de n’importe quel outil de contrôle. Leur lecture la désamorce en une minute : cinq sont des fichiers de protection de 27 octets posés par des extensions, six sont vides, et la plus récente date de 2024. Compter les PHP sous les médias ne suffit pas, il faut les ouvrir.
Questions fréquentes
Mon site refuse d’installer une extension, faut-il passer en 777 ?
Non. Cette erreur vient presque toujours du propriétaire des fichiers, différent du compte sous lequel PHP s’exécute. C’est ce réglage qu’il faut corriger, chez l’hébergeur, et pas la valeur des permissions. Le 777 fait disparaître le message sans traiter la cause, et ouvre l’écriture à toute la machine.
Comment vérifier les permissions sans accès en ligne de commande ?
Le gestionnaire de fichiers de l’hébergement et n’importe quel client FTP affichent et modifient la valeur, souvent sous le nom CHMOD, avec une application récursive à un répertoire entier. En SSH, la même opération se fait en une commande.
Est-ce la même chose que les rôles d’utilisateurs WordPress ?
Non, et la confusion est fréquente parce que les deux se disent permissions. Les rôles d’utilisateurs, administrateur, éditeur, auteur, contributeur, abonné, décident de qui peut faire quoi dans le tableau de bord. Les autorisations décrites ici décident de qui peut lire et écrire sur le serveur, un niveau en dessous, et elles s’appliquent même quand WordPress ne tourne pas.
Des permissions correctes suffisent-elles à sécuriser un site ?
Non, et ce n’est pas leur rôle. Elles limitent les dégâts après une entrée. Les mises à jour, la solidité des comptes et la suppression des extensions abandonnées restent ce qui empêche l’entrée elle-même.
Faut-il tout remettre en 755 et 644 après un piratage ?
Oui, mais après avoir relevé l’état existant. Les permissions anormales font partie des indices qui racontent ce qui s’est passé : les réinitialiser d’abord efface une trace utile.
Sources
Et sur votre site ?
Une définition ne dit pas si vous êtes concerné.
L'audit gratuit répond dans votre cas : état technique, temps de chargement, et ce que Google voit réellement de vos pages. Un constat écrit, sans engagement et sans jargon.