Sur une installation WordPress, les permissions de fichiers ressemblent parfois à un détail d’hébergement, un réglage “technique” laissé aux administrateurs. En pratique, c’est souvent l’un des points qui font la différence entre un site simplement “verrouillé” et un site réellement résilient. Quand un attaquant vise WordPress, il cherche moins à “hacker” au sens noble qu’à abuser d’un maillon faible, surtout si un compte a déjà pris une teinte de légitimité ou si un plugin a créé une faille d’écriture.
Verrouiller les permissions, c’est réduire la surface d’attaque liée à l’écriture de fichiers. Pas en rêvant d’un monde où tout est impossible, mais en imposant des règles strictes sur ce qui peut être modifié, par qui, et dans quel cadre. Et cela inclut un élément souvent oublié : l’équilibre entre sécurité et fonctionnement. Un mauvais réglage peut casser WordPress, bloquer l’upload d’images, ou empêcher WordPress de mettre à jour des thèmes et plugins. L’objectif, c’est de viser le “minimum nécessaire”.
Pourquoi les permissions comptent vraiment
WordPress fonctionne grâce à des fichiers PHP exécutés par le serveur, à des répertoires qui doivent parfois accepter des écritures (uploads, certaines caches), et à des outils d’administration qui déclenchent des opérations d’écriture. Si le serveur accepte trop largement l’écriture, vous offrez une porte plus facile à toute compromission, même partielle.
Imaginons un scénario classique vécu sur plusieurs environnements : un plugin mal configuré ou vulnérable permet à un attaquant de déposer un fichier dans le répertoire du site. Si les permissions sont généreuses, l’écriture peut réussir sans obstacle, et l’attaquant obtient un script prêt à être exécuté. Si, au contraire, les répertoires sensibles sont strictement protégés, l’attaque peut rester bloquée sur une simple tentative.
Ce n’est pas seulement une question de “qui peut écrire”. Les permissions influencent aussi la capacité du système à protéger l’arborescence contre des erreurs humaines. J’ai vu des environnements où un simple chmod “parce que ça marche” a ouvert davantage que prévu, puis des mois plus tard, un backup corrompu ou une mise à jour a révélé que le site n’était plus dans un état cohérent. Des permissions cohérentes, maintenues dans le temps, aident à conserver un comportement prévisible.
Comprendre ce que vous modifiez : mode, propriétaire, groupe
Avant de changer quoi que ce soit, je conseille de clarifier trois notions, parce que les “chiffres” sans contexte mènent aux erreurs :
- Le mode (les chiffres comme 640, 644, 755) décrit les droits pour le propriétaire, le groupe, et les autres. Le propriétaire et le groupe déterminent qui correspond à “vous” et qui correspond à “le reste”. Le serveur web (souvent “www-data”, “apache”, ou l’utilisateur PHP-FPM selon la config) doit avoir exactement les droits nécessaires pour servir le site et écrire là où c’est requis.
Beaucoup d’histoires de mauvais réglages viennent d’un malentendu simple : le site tourne avec un utilisateur différent de celui que l’administrateur croit “posséder” les fichiers. Par exemple, sur certains hébergements, les fichiers peuvent être initialement créés par un compte FTP, puis le serveur web tourne sous un autre utilisateur. Du coup, donner des droits “au hasard” ne garantit rien, sauf d’ouvrir plus que nécessaire.
Si vous avez accès au terminal, ou via un outil de gestion (SSH, panel d’hébergement), le bon réflexe est de vérifier le propriétaire et le groupe actuels avant de changer les modes.
Les principes de verrouillage qui tiennent dans la durée
Renforcer sécurité WordPress, ce n’est pas un coup de pinceau ponctuel, c’est une discipline. Trois principes reviennent presque toujours, quelles que soient les spécificités de votre serveur.
D’abord, les fichiers “servis” doivent être lisibles, rarement écrits. Les fichiers PHP du cœur de WordPress, les fichiers de thèmes et de plugins ne devraient pas être modifiables en permanence par le processus web. Ils doivent pouvoir être lus, exécutés (pour PHP), mais pas “écrits”.
Ensuite, les répertoires “écrivables” doivent être limités. Le plus évident est wp-content/uploads, qui sert aux médias. Le répertoire wp-content peut aussi accueillir des caches ou d’autres écrits, mais c’est justement là qu’il faut être prudent : plus vous élargissez, plus vous donnez de marge à une compromission.
Enfin, les permissions doivent rester cohérentes. Une règle stricte qui se dégrade au fil des mises à jour ou des déploiements (thèmes mis à jour, plugins installés, uploads effectués) finit par créer des exceptions. Le bon compromis, c’est de verrouiller fort par défaut, puis de laisser WordPress et le serveur écrire uniquement ce qui doit l’être, avec des permissions cohérentes.
Cas d’usage : où WordPress écrit réellement
Sans inventer une liste figée, il existe des catégories assez stables.
Le stockage des médias est le cas le plus constant. wp-content/uploads doit autoriser l’écriture, sinon les uploads cassent et certains traitements d’images échouent.
Ensuite, selon les plugins et votre configuration, des écritures peuvent apparaître dans wp-content pour des caches, des fichiers temporaires, des logs, parfois des index. Les mises à jour automatiques peuvent aussi déclencher des opérations d’écriture ailleurs dans l’arborescence, le temps de remplacer des fichiers.
C’est là que beaucoup de gens se trompent : ils “verrouillent” en permanence sans tenir compte du cycle de mise à jour. En sécurisant trop, vous forcez soit un mode “tout est ouvert”, soit des contournements (uploads via un compte différent, ou corrections manuelles après chaque mise à jour). Le but est de faire en sorte que le système puisse fonctionner, tout en minimisant ce qui reste modifiable.
Les cibles typiques : fichiers à 644 et répertoires à 755, avec nuance
Dans l’univers Linux, on rencontre souvent la recommandation suivante pour WordPress :
- fichiers : 644 (lecture pour tous, écriture uniquement pour le propriétaire) répertoires : 755 (lecture et exécution pour tous, écriture uniquement pour le propriétaire)
Pourquoi cette logique ? Parce que les fichiers de code n’ont pas besoin d’être écrits par “tout le monde”, alors que les répertoires doivent pouvoir être traversés par le serveur pour servir le contenu. L’exécution n’est pertinente que pour les répertoires, car pour les fichiers PHP, c’est le serveur qui exécute, pas la permission “x” au sens où un binaire le ferait dans un contexte shell.
Mais la nuance essentielle, c’est que wp-content/uploads (et parfois certains sous-répertoires) doit autoriser l’écriture pour le processus web. Le mode exact dépend de votre architecture (droit d’exécution, umask, utilisateur PHP-FPM, présence de ACL, etc.). Un réglage trop permissif partout reste une mauvaise idée, même si “ça marche”.
J’ai déjà vu des sites où tout a été mis à 777 par panique, puis où un audit a révélé qu’un attaquant n’aurait eu qu’à écrire un fichier dans un répertoire trop large. Si vous tenez à une règle simple, retenez celle-ci : on limite les répertoires écrits aux emplacements strictement nécessaires, pas au niveau de “toutes les arborescences”.
Procédure prudente avant de modifier quoi que ce soit
La tentation est grande de “corriger” dès maintenant avec des chmod globaux. C’est rarement la bonne approche. Un changement global peut :
- empêcher l’upload d’images, casser la mise à jour automatique, provoquer des erreurs de permissions liées à des caches ou à certains plugins, laisser un mélange de droits incohérent après coup.
La méthode la plus sûre consiste à faire un diagnostic rapide, puis à appliquer des règles ciblées.
Mini check rapide (sans prise de risque inutile)
Vérifiez le propriétaire et le groupe des dossiers et fichiers WordPress (pas juste les chiffres). Identifiez l’utilisateur sous lequel tourne le serveur web ou PHP-FPM. Testez un upload dans l’interface, une fois, avant toute modification. Prenez une sauvegarde et, idéalement, un snapshot du dossier web. Appliquez les changements en commençant par les répertoires non sensibles.Cette séquence évite les “surprises” du type “là, ça ne marche plus” sans savoir d’où vient l’erreur. Elle évite aussi de perdre du temps à reconstruire un état correct à la main.
Les actions concrètes pour verrouiller
Selon votre accès, vous pouvez agir via FTP/SFTP, via un panel d’hébergement, ou via SSH. Les panneaux sont pratiques, mais ils ne donnent pas toujours le bon niveau de contrôle, surtout si vous devez gérer des récursions fines.
Si vous avez la main via SSH, l’approche la plus saine consiste à :
- verrouiller les fichiers (mode plus restrictif), verrouiller les répertoires sensibles, ouvrir uniquement les répertoires d’uploads et les répertoires qui doivent réellement écrire.
Le détail du “qui écrit” est critique. Si votre serveur PHP-FPM tourne sous www-data, alors c’est le groupe ou le propriétaire de vos répertoires écrits qui doit correspondre, sinon vous allez devoir ouvrir davantage que nécessaire pour compenser.
Je garde une règle mentale : on préfère ajuster le propriétaire et le groupe des dossiers d’écriture plutôt que de donner des droits “pour tout le monde”.
Exemple de logique de droits (à adapter à votre hébergement)
Sur beaucoup d’installations, la logique fonctionne comme suit :
- Pour le code WordPress, thèmes et plugins : 644 pour les fichiers, 755 pour les dossiers. Pour wp-content/uploads : un mode permettant au processus web d’écrire. Pour certains sous-dossiers de cache : permissions compatibles avec leur besoin d’écriture, souvent plus restrictif que des permissions “large open”.
Selon les environnements, la meilleure pratique peut inclure un umask spécifique ou l’usage de groupes partagés, pour que les fichiers créés lors des uploads héritent de la bonne appartenance.
Je n’écris pas ici de commande “une ligne pour tous les cas”, parce que la même commande peut ruiner un autre serveur si l’utilisateur diffère. Le bon compromis, c’est d’adapter à votre arborescence réelle.
ACL, groupes et le piège des “777”
Les ACL (Access Control Lists) permettent d’être fin, parfois très fin. Au lieu de s’appuyer uniquement sur les trois catégories du mode standard, vous pouvez exprimer des droits additionnels au niveau des répertoires ou des fichiers.
Si votre hébergement supporte ACL et si vous avez une discipline d’exploitation, c’est une voie intéressante pour renforcer sécurité WordPress sans rendre le site fragile. Par exemple, vous pouvez autoriser l’écriture sur uploads pour un groupe spécifique, tout en gardant le reste strict.
Le piège, ce sont les solutions de contournement rapides. J’ai vu des équipes remplacer des permissions trop strictes par du 777, parce que “les uploads marchent”. Cette “solution” dégrade la sécurité de manière irréversible à l’échelle du risque : dès qu’un attaquant gagne un point d’écriture, il dispose d’un levier plus large. Même si l’attaque ne passe pas, vous perdez le bénéfice du verrouillage que vous cherchez.
Si vous tombez sur des permissions très ouvertes, la question à poser n’est pas “pourquoi WordPress ne marche pas avec moins”, mais “pourquoi on en est arrivé là”. Souvent, la réponse est un incident ancien, une mauvaise procédure de déploiement, ou un changement de propriétaire après migration.
Gérer les mises à jour sans redonner trop de droits
Un point subtil : les mises à jour de WordPress et des plugins peuvent nécessiter des opérations d’écriture. Si votre stratégie consiste à maintenir tout en lecture seule, vous allez soit perdre des mises à jour automatiques, soit devoir faire des ajustements temporaires.
Mon approche pragmatique ressemble à ceci : je garde le site verrouillé en temps normal, mais je prévois une procédure “maintenance” pour les mises à jour. Cette procédure consiste à autoriser temporairement l’écriture sur les emplacements strictement nécessaires, puis à revenir à l’état sécurisé.
Le bénéfice est double. D’abord, vous évitez l’état permanent “trop ouvert”. Ensuite, vous gardez une traçabilité, parce que la phase de mise à jour suit une routine.
Vous pouvez aussi envisager d’effectuer les mises à jour via un compte d’administration plus strict côté serveur, ou via votre système de déploiement. Dans ce cas, l’écriture est faite par un utilisateur contrôlé, plutôt que par le processus web dans un contexte permanent.
Ce qu’il faut surveiller après changement de permissions
Après un verrouillage, WordPress peut sembler “OK” pendant une minute, puis révéler des erreurs quelques heures plus tard, quand un plugin tente une écriture de cache, ou quand un traitement d’image s’exécute.
Voici les signaux à garder en tête, sans en faire une liste exhaustive. En pratique, les erreurs “à l’écran” lors des uploads sont un bon indicateur, mais les traces dans les logs sont souvent plus révélatrices. Si vous avez accès aux logs d’erreur du serveur ou à ceux de PHP, regardez-les après vos tests : c’est là que vous verrez si WordPress échoue à créer un fichier, ou si un plugin demande des droits sur un dossier inattendu.
Les autres symptômes fréquents sont plus “fonctionnels” :
- médias qui ne s’enregistrent pas, avatars qui échouent, mise en cache qui ne se fait pas, retours d’erreur sur des actions d’administration.
Ces problèmes sont généralement liés à l’incompatibilité entre le processus web et le propriétaire/groupe des répertoires ciblés. Ils se règlent en ajustant le groupe ou en ciblant uploads plutôt que de rouvrir le reste du site.
Comparer deux stratégies : verrouillage strict vs compromis opérationnel
Dans les environnements réels, il existe un compromis. On peut viser un verrouillage strict en empêchant toute écriture du processus web hors uploads, ou accepter un périmètre légèrement plus large pour éviter la fragilité.
| Stratégie | Avantage | Risque principal | Quand l’utiliser | |---|---|---|---| | Verrouillage strict (code en lecture seule, uploads seul écrivant) | Réduit la surface d’écriture | Peut casser certains plugins de cache ou logs si non anticipés | Sites avec peu de plugins, architecture maîtrisée, discipline de maintenance | | Compromis (uploads + quelques répertoires de cache/logs) | Moins de casse fonctionnelle | Augmente la zone “écrivable” si trop large | Sites avec plugins variés, besoins de cache, gestion d’extensions | | “Ouverture large” temporaire (périodes maintenance) | Maintient la sécurité en temps normal | Nécessite un process de maintenance solide | Équipes qui savent planifier les updates et revenir à l’état sécurisé |
L’important est de ne pas laisser le compromis devenir un état permanent. Si vous choisissez une stratégie plus souple, documentez-la et surveillez les répertoires réellement écrits.
Construire une routine de contrôle (simple et efficace)
Beaucoup de sites ne “dérapent” pas d’un coup. Le verrouillage initial tient, puis des modifications progressives viennent le grignoter : déploiements manuels, migrations, changement d’utilisateur FTP, installation de plugin qui écrit dans un dossier inattendu, puis une correction maladroite.
Une routine de contrôle, même légère, fait une différence. Vous n’avez pas besoin d’un outil complexe, mais vous avez besoin d’un repère.
Vous pouvez, par exemple, comparer les permissions des dossiers critiques à un état connu, et contrôler régulièrement que uploads reste le principal répertoire écrivable. Si vous observez des droits qui s’étendent hors du périmètre attendu, c’est un signal de dérive.
Sur des projets qui tournent depuis longtemps, j’aime aussi instaurer une règle de “qui change quoi” : quand une mise à jour est faite, on vérifie le résultat. Quand un plugin est installé, on contrôle la cohérence des permissions. Cela évite la situation où tout le monde agit “au feeling”.
Cas particuliers qui méritent une attention
Certains environnements sont plus sensibles :
- installations derrière un reverse proxy avec un utilisateur système spécifique, hébergement qui utilise des conteneurs ou des environnements partagés, montages de stockage (NFS, volumes) qui peuvent imposer des comportements différents, environnements Windows via FTP (moins recommandé pour la cohérence fine des permissions, mais possible).
Dans ces cas, les chiffres de permissions peuvent ne pas suffire à garantir la même sécurité, parce que le système de fichiers et la façon dont l’hébergement gère l’écriture peuvent changer la réalité. Le bon réflexe est de tester sur vos cas d’usage, uploads et mise à jour, puis d’ajuster en conséquence.
J’ajoute un point : si votre hébergement fournit déjà des recommandations de droits spécifiques, elles doivent primer sur des recettes génériques. La recette “644 et 755” est une base robuste, mais l’exact ajustement dépend du contexte.
Pièges courants quand on essaie de verrouiller
Le premier piège, c’est le changement récursif trop large sans vérifier l’utilisateur. Un chmod récursif peut changer des droits dans des zones qui ne devraient pas bouger, y compris des fichiers de configuration sensibles.
Le deuxième piège, c’est d’ignorer les sous-répertoires dans uploads. Certains plugins créent des dossiers spécifiques dans uploads et y écrivent. Si vous verrouillez un niveau trop haut de https://gardewp.fr/securite-wordpress/ manière trop stricte, vous aurez des erreurs aléatoires, souvent après une action précise.
Le troisième piège, c’est le mélange entre propriétaire et groupe. Si WordPress écrit mais laisse des fichiers appartenant à un autre utilisateur, vous aurez un effet cumulatif : un jour, le système ne pourra plus écrire parce que le propriétaire a changé lors d’une opération précédente.
Enfin, il y a le piège “on fait ça vite”. La sécurité, surtout sur les permissions, récompense la précision. Une minute de diagnostic vaut souvent une heure de corrections après coup.
Un dernier mot sur l’équilibre sécurité et maintenance
Verrouiller les permissions fichiers est un excellent levier pour renforcer la sécurité autour de WordPress, parce que vous réduisez les possibilités d’écriture exploitables. Mais cela ne remplace pas les autres fondamentaux, mises à jour, durcissement de l’accès, vérification des plugins, gestion des comptes. Les permissions sont une barrière. Une barrière efficace, mais une barrière.
Si vous voulez une règle de conduite, elle pourrait se résumer ainsi : visez un état dans lequel WordPress sert et permet ce qui est nécessaire, mais où la surface d’écriture reste confinée. Ensuite, gardez une routine simple de contrôle. C’est ce qui transforme un “réglage ponctuel” en vraie posture de renforcement.
Si vous me décrivez votre environnement (hébergement, utilisateur web ou PHP-FPM, et ce que vous observez comme erreurs éventuelles), je peux vous aider à traduire la logique en réglages adaptés, sans casser uploads ni les mises à jour.
