Quand on parle de sécurisation WordPress, on pense souvent au thème du durcissement côté appli, aux mises à jour, aux plugins de sécurité et aux mots de passe. Pourtant, une porte d’entrée très concrète se joue à un niveau plus bas: le système de fichiers et ce que votre serveur autorise à lire, écrire ou exécuter.
Les permissions ne sont pas un “bouton sécurité” magique. Mal réglées, elles peuvent créer des erreurs visibles (écrans blancs, uploads impossibles, thèmes ou plugins qui ne se chargent plus). Pire, elles peuvent exposer des fichiers sensibles à la lecture publique, ou permettre à un compte compromis d’agir plus facilement que nécessaire.
Je vais vous guider sur les permissions de fichiers et de dossiers qui reviennent le plus souvent dans WordPress, avec les pièges typiques, les arbitrages réalistes et une méthode pour corriger sans casser votre site.
Comprendre ce que WordPress attend vraiment
Sous Linux, les permissions se déclinent généralement en trois catégories:
- l’utilisateur propriétaire du fichier (souvent le même compte que PHP utilise) le groupe les autres
À cela s’ajoute le bit “exécution”, qui n’a pas la même signification selon le type de fichier. Un dossier “execute” permet en pratique de traverser le chemin, donc d’y accéder. Un fichier “execute” n’est utile que dans des cas très particuliers.
WordPress, de manière simplifiée, a besoin de deux choses:
Pouvoir exécuter le code PHP dans son répertoire (le noyau, les thèmes, les plugins). Pouvoir écrire dans des emplacements précis pour gérer les contenus, les caches et, selon votre configuration, certaines parties de l’interface d’administration.
Le point clé, c’est que tout le reste n’a pas vocation à être modifiable par tout le monde. Les autorisations “large” (par exemple 777) réduisent le coût de maintenance au moment de l’installation, mais elles augmentent la surface de risque si un autre morceau du système est déjà fragilisé.
Les valeurs les plus courantes (et pourquoi elles fonctionnent)
Sur WordPress, les réglages qui reviennent le plus souvent en production sont:
- fichiers PHP: droits de lecture et d’exécution pour le serveur, lecture seule pour le groupe et les autres dossiers: droits de traversée, lecture et éventuellement écriture sur les emplacements où WordPress écrit
En pratique, on voit presque toujours les patterns suivants sur des serveurs Linux:
- fichiers: 644 dossiers: 755 dossiers d’uploads et de caches: souvent 755 côté dossiers, et 644 côté fichiers (mais avec écriture autorisée là où c’est nécessaire)
Le chiffre traduit une combinaison de droits. Sans rentrer dans toute la théorie, l’idée est simple: le serveur peut lire, exécuter, et WordPress peut écrire uniquement quand il doit le faire.
Voici les repères utiles, à appliquer avec discernement selon votre hébergement et votre mode de fonctionnement (compte PHP, propriétaire des fichiers, environnement).
- Fichiers WordPress (PHP, CSS, JS, etc.): 644 Dossiers WordPress (racine, wp-content, thèmes, plugins): 755 Répertoire uploads (wp-content/uploads): 755 pour les dossiers, 644 pour les fichiers, tout en laissant WordPress écrire wp-config.php: 640 ou 600 selon votre configuration, jamais “grand public” Répertoires qui doivent être écrits par PHP (souvent caches et uploads): aligner sur votre besoin réel, typiquement 755 pour les dossiers
Ces valeurs ne sont pas une loi universelle. Sur certains hébergements, vous n’avez pas le même compte utilisateur, ou PHP s’exécute sous un autre identifiant. Là, la permission “chiffrée” correcte ne sert à rien si le propriétaire et le groupe ne correspondent pas à l’exécution PHP.
Propriétaire et groupe: le vrai nerf de la guerre
Si vous ne corrigez que les chiffres, mais pas le propriétaire (owner) et le groupe (group), vous pouvez vous retrouver avec des permissions “parfaites” qui ne fonctionnent pas.
Un scénario fréquent: vous copiez une sauvegarde ou vous déployez via un outil qui crée des fichiers appartenant à un autre utilisateur du système. Résultat, PHP tente d’écrire dans wp-content/uploads, mais n’a pas les droits. Vous voyez alors:
- des médias qui n’arrivent pas à s’ajouter des fichiers temporaires incapables d’être créés parfois des erreurs dans la médiathèque, ou un “upload failed”
Dans ce cas, la bonne correction est souvent un chown ou un changement de propriétaire via votre interface d’hébergement, suivi d’un ajustement plus léger des permissions.
La règle pratique que je suis dans les interventions: d’abord stabiliser la relation entre le compte qui exécute PHP et le propriétaire des dossiers sensibles. Ensuite seulement, harmoniser les chmod.
Les dossiers qui posent le plus de questions
Sur WordPress, les permissions “à risque” ou “à impact immédiat” sont celles des répertoires où l’application écrit.
wp-content/uploads est le candidat numéro un, parce que l’utilisateur ajoute des médias, et WordPress génère parfois des versions redimensionnées.
wp-content et ses sous-dossiers demandent aussi de la prudence. Si vous activez un système de cache (plateforme, plugin, optimisation), un répertoire de cache protéger données clients WordPress peut se créer et recevoir des écritures. Souvent, ce sont des dossiers du style wp-content/cache ou wp-content/uploads/cache selon les solutions. Le pattern général reste 755 pour les dossiers et 644 pour les fichiers, mais ce qui compte vraiment, c’est que PHP possède les droits.
Enfin, selon les plugins, vous pouvez avoir des répertoires additionnels (sauvegardes, logs, fichiers temporaires, miniatures). Ici, la tentation est grande de donner l’accès en écriture “partout”, alors qu’il suffit de cibler le bon endroit.
J’ai vu des sites qui fonctionnaient pendant des mois avec des permissions très larges, puis une mise à jour a changé le comportement d’un plugin et tout a basculé: le plugin a tenté d’écrire dans un dossier nouvellement utilisé, et tout le monde s’est retrouvé avec un site cassé ou, pire, une écriture plus permissive que prévu.
wp-config.php: le fichier qu’on ne traite pas comme les autres
wp-config.php contient des secrets, des identifiants et des paramètres sensibles. Même si l’accès direct au fichier est bloqué par la configuration serveur, vous ne gagnez rien à exposer ce fichier à une lecture “large”.
Dans une démarche pragmatique, je vise une permission qui limite l’accès aux seuls comptes nécessaires. Sur la plupart des setups, 600 ou 640 est un bon point de départ. Le choix exact dépend du propriétaire du fichier et de la manière dont PHP est exécuté.
Si vous travaillez avec plusieurs environnements (dev, staging, prod), vérifiez que votre pipeline de déploiement conserve bien ces paramètres. Les transferts FTP ou certains outils “réinstallent” des permissions par défaut, et ce qui était correct en local devient trop ouvert en production.
Ce qui casse vite: erreurs typiques à reconnaître
Les problèmes de permissions se manifestent souvent par des symptômes très concrets. Quelques exemples que vous aurez peut-être déjà croisés:
- Le site charge le front, mais l’administration affiche des erreurs ou un écran blanc. La médiathèque ne permet pas de téléverser. L’activation d’un thème ou d’un plugin échoue, ou les mises à jour échouent. Un plugin de cache ne crée plus ses fichiers, et vous avez des comportements incohérents.
La bonne approche, avant de “mettre 777 partout”, est de vérifier:
Qui est propriétaire des fichiers et dossiers concernés. Quels répertoires ont besoin d’écriture d’après vos symptômes. Quelles erreurs exactes s’affichent (et surtout ce que renvoient les logs serveur et PHP).Sur un hébergement mutualisé, vous n’avez pas toujours accès aux logs au détail, mais vous pouvez souvent obtenir l’erreur précise liée à l’échec d’écriture, par exemple une trace qui mentionne le chemin du dossier que PHP n’arrive pas à ouvrir ou à créer.
Méthode fiable pour corriger sans dégrader la sécurité
La correction des permissions n’est pas seulement un “remettre comme avant”. Elle doit rester cohérente avec votre mode de déploiement.
Voici la démarche que je recommande, dans l’ordre, pour minimiser les dégâts:
Identifiez l’étendue du problème: quel dossier ou fichier pose problème, et est-ce un souci d’écriture, de lecture, ou d’exécution. Vérifiez les propriétaires: sur Linux, l’écart owner/group est souvent la cause cachée. Appliquez des permissions minimales: commencez par les répertoires qui doivent être écrits, pas par tout WordPress. Testez par étapes: après chaque ajustement, vérifiez une action concrète (upload, activation d’un plugin, génération d’un cache). Conservez une référence: idéalement, notez les valeurs avant modification pour revenir si un cas edge se révèle.Un détail important: si vous corrigez “en vrac” tout le dossier WordPress, vous risquez de changer les permissions de fichiers ou dossiers qui avaient été volontairement durcis. Dans une logique de sécurité, mieux vaut cibler.
Exemple de scénario réel: uploads cassés après changement d’hébergement
J’ai déjà vu un site migré vers un nouvel hébergement. Les permissions chiffrées ressemblaient à ce qu’on attendait, mais l’uploads était KO. Le front fonctionnait, donc PHP exécutait le code. Pourtant, l’administration refusait les médias.
En inspectant la structure, on a constaté que wp-content/uploads avait un propriétaire différent. Les permissions de type 755 et 644 étaient présentes, mais le serveur n’était pas le bon propriétaire, donc il n’avait pas les droits d’écriture quand WordPress tentait de créer des sous-dossiers ou des fichiers temporaires.
La correction a consisté à réaligner owner et groupe sur le compte PHP, puis à réappliquer les perms standards sur les emplacements d’écriture. Résultat: tout a refonctionné sans élargir au-delà du nécessaire.
Ce genre de cas explique pourquoi je recommande de raisonner “cible de l’écriture” et “identité système”, plutôt que de jouer uniquement avec les 777.
Cas limites: quand “ça doit être écrit” devient flou
Certaines configurations de WordPress impliquent davantage d’écriture: mise à jour via le navigateur, création de répertoires temporaires, génération de fichiers pendant l’optimisation d’images, certains plugins de sécurité qui écrivent des logs, ou encore des systèmes de cache.
Le piège, c’est d’interpréter “WordPress a besoin d’écrire” comme une autorisation à écrire partout. Ce n’est pas le cas.
Pour garder le contrôle, je traite les dossiers “à risque” séparément. Si un plugin indique qu’il a besoin d’un droit d’écriture, je cible uniquement le répertoire qu’il utilise. Si vous ne connaissez pas ce répertoire, testez en observant le comportement ou les messages d’erreur, plutôt qu’en donnant un accès global.
Autre cas limite: la commande récursive de permissions. Beaucoup de guides proposent de faire des chmod récursifs sur wp-content. Ça peut être utile pour corriger une catastrophe, mais c’est dangereux si vous avez des fichiers spécifiques dont les permissions étaient volontairement différentes (par exemple des fichiers générés par un outil d’optimisation, des uploads avec des attributs particuliers, ou des répertoires créés par des services distincts).
Si vous devez le faire, faites-le en comprenant les conséquences et, si possible, commencez par un sous-dossier.
Déverrouiller un symptôme sans ouvrir une faille
Votre objectif n’est pas seulement de faire fonctionner WordPress, c’est aussi d’éviter de créer des permissions trop permissives. Un bon exemple est le réflexe “mettre 777 sur wp-content”.
Sur le plan sécurité, 777 signifie que n’importe quel utilisateur du système peut écrire dans ces dossiers, ce qui augmente le risque en cas de compte compromis ou de mauvaise configuration ailleurs.
Une approche plus saine consiste à réduire le problème à son périmètre minimal. Si vous devez faire une correction temporaire, vous pouvez le faire, mais avec un plan de retour et une durée limitée, puis vérifier que WordPress écrit bien dans le bon endroit avant de revenir à des valeurs plus strictes.
Voici un guide de lecture des situations les plus courantes, utile pour choisir où agir (et où ne pas surcorriger):
- Upload impossible: vérifier wp-content/uploads et l’owner du dossier, pas seulement le chmod Mises à jour plugin ou thème en échec: cibler le dossier d’extraction et les droits d’écriture dans wp-content Écran blanc côté administration: suspecter un fichier non accessible ou un dossier bloquant une écriture de cache, vérifier logs PHP Erreur sur création de répertoires: repérer le dossier exact mentionné dans le message, puis ajuster owner et perms uniquement là Cache qui ne se génère pas: corriger le répertoire de cache utilisé par le plugin, pas tout WordPress
Ce raisonnement réduit la tentation d’élargir trop large, tout en accélérant le diagnostic.
Comment appliquer les changements concrètement (sans magie)
Vous avez généralement trois moyens pour modifier permissions et propriétaires:
- un gestionnaire de fichiers dans l’interface d’hébergement (souvent simple, mais parfois trop “global”) un accès SSH avec commandes (le plus précis, mais plus exigeant) un outil de déploiement automatisé (le plus propre si bien configuré)
Si vous travaillez via SSH, vous rencontrerez souvent chmod pour les droits et chown pour owner/group. Le piège, c’est le caractère récursif et les erreurs de cible. Une commande récursive mal formulée peut élargir des permissions sur des dossiers non prévus.
Si vous travaillez via une interface graphique, la logique est parfois plus sûre, parce que vous limitez visuellement les zones, mais elle peut aussi être moins fine. Par exemple, vous ne choisissez pas toujours le comportement récursif, et certains hébergeurs imposent des contraintes sur les permissions que vous pouvez modifier.
Dans tous les cas, je recommande de prendre une photo ou une trace des permissions avant modification sur les dossiers concernés. Sur un site vivant, cela peut sauver plusieurs heures lorsque la réparation initiale n’est pas la correction finale.
Les permissions ne remplacent pas les autres couches de sécurité
Mettre les bonnes permissions aide beaucoup, mais ne suffit pas à elle seule. Le serveur doit aussi empêcher l’accès direct aux fichiers sensibles, et WordPress doit être mis à jour. Les permissions protègent contre des comportements “basiques” en cas de problème, mais une faille applicative ou une injection exploitable ne disparaît pas parce que vous avez réglé 644 et 755.
C’est la combinaison qui compte: permissions minimales, mises à jour à jour, accès admin protégé, durcissement réseau, et configuration serveur cohérente.
Si vous avez déjà activé des règles de sécurité, vérifiez aussi la compatibilité. Certains durcissements serveur peuvent bloquer l’écriture dans des dossiers que WordPress utilise, ou empêcher des scripts d’exécution attendus. Dans ce cas, les permissions corrigées ne seront pas la seule cause.
Vérifier après coup: ce qui rassure vraiment
Une fois vos permissions ajustées, ne vous contentez pas de “ça a l’air”. Vérifiez avec des actions typiques:
- téléverser un média activer ou mettre à jour un plugin en test (sur un staging si possible) déclencher la génération d’un élément que votre configuration utilise (cache, miniatures, optimisation)
Sur un site de production, vous pouvez choisir une action peu risquée, par exemple téléverser une image test, puis vérifier que les fichiers apparaissent bien dans wp-content/uploads avec le propriétaire attendu.
Cette validation vous évite le piège inverse: un site “fonctionnel” pour le moment, mais avec des permissions plus ouvertes que nécessaire, ou au contraire avec une erreur latente qui bloquera la prochaine mise à jour.
Une règle simple pour ne pas tomber dans le piège
Si je devais résumer la logique en une seule idée: WordPress doit pouvoir écrire uniquement là où il a une raison précise, et le reste doit rester lisible et exécuté, pas modifiable.
Sur le plan pratique, ça signifie:
- des permissions standard (644 pour les fichiers, 755 pour la plupart des dossiers) des exceptions ciblées pour l’écriture (uploads, répertoires de cache, dossiers de plugins qui écrivent réellement) un wp-config.php verrouillé un propriétaire et un groupe cohérents avec l’exécution PHP
C’est moins spectaculaire que “installer un plugin de sécurité”, mais c’est souvent ce qui fait la différence quand un site semble sécurisé puis échoue soudainement, à la suite d’une migration, d’une mise à jour ou d’un changement d’hébergement.
Si vous me décrivez votre hébergeur (mutualisé, VPS, container), et l’erreur exacte que vous voyez (upload, mises à jour, ou écran blanc), je peux vous proposer un plan de correction plus ciblé, avec les dossiers à vérifier en priorité.