Sécurité WordPress professionnelle : configurer correctement les permissions

La sécurité d’un site WordPress ne tient pas uniquement à la version du CMS ou au plugin “anti”. Elle passe aussi par des choses très concrètes, souvent sous-estimées. Les permissions de fichiers et de dossiers, par exemple, sont un levier puissant, à condition d’être réglées avec discernement.

Quand une installation est mal “droitisée”, deux scénarios se répètent sur le terrain. Le premier, c’est le blocage, l’éditeur ne peut plus enregistrer, les mises à jour échouent, des pages renvoient des erreurs 500. Le second, plus grave, c’est la sur-autorisation, quand un processus d’écriture se retrouve plus large que nécessaire. Dans ce cas, un accès limité peut devenir une capacité d’écriture plus dangereuse, et l’attaquant n’a plus qu’à déposer un fichier, ou modifier du contenu au mauvais endroit.

Dans une approche de sécurité site WordPress professionnel, les permissions doivent servir un objectif simple: réduire les possibilités d’écriture non indispensables, tout en garantissant la maintenance normale du site.

Comprendre ce que représentent vraiment les permissions

Sur un serveur Linux, les permissions reposent sur trois catégories: l’utilisateur propriétaire, le groupe, et tout le reste. À cela s’ajoute la capacité de lire, écrire, exécuter. Pour WordPress, ce que vous voulez viser dépend de la nature du répertoire:

• Les fichiers de configuration et certains fichiers du noyau WordPress doivent être lisibles, mais rarement modifiables par “n’importe qui”.
• Les répertoires destinés aux uploads et à la mise en cache doivent pouvoir recevoir des écritures, mais uniquement par l’utilisateur du serveur web (souvent www-data, apache, nginx ou un utilisateur dédié).
• Les répertoires temporaires et certains caches doivent aussi écrire, sinon vous verrez des erreurs discrètes, du type “Échec de la création du répertoire” ou des mises à jour qui n’écrivent pas les fichiers.

Le piège, c’est de traiter les permissions comme un réglage universel. En pratique, l’organisation des utilisateurs, le type de serveur (Apache ou Nginx, PHP-FPM ou mod_php), la manière dont votre hébergeur expose les droits, tout cela influence le bon réglage.

J’ai vu des environnements où tout fonctionnait avec des permissions “larges”, puis où une mise à jour de PHP ou du mode de déploiement a brusquement cassé le site. À l’inverse, j’ai vu des sites qui étaient “cassés” parce que quelqu’un avait appliqué une recette trouvée sur un forum, sans vérifier l’utilisateur réel côté serveur.

Les droits les plus fréquents et pourquoi ils posent problème

La plupart des soucis de permissions viennent de deux excès: trop ouvert, ou trop fermé.

Permissions trop ouvertes

Quand des fichiers sensibles sont modifiables par des comptes non nécessaires, vous augmentez la surface d’attaque. Par exemple, donner des droits d’écriture à des dossiers qui ne devraient écrire que pour les uploads peut permettre des écritures persistantes. Même si WordPress est robuste sur la partie applicative, l’OS garde la porte ouverte si les permissions le permettent.

Un autre cas fréquent: des permissions “génériques” sur l’ensemble de /wp-content. Les plugins, thèmes, fichiers médias et caches vivent dans le même ensemble logique, mais n’ont pas les mêmes besoins. Une règle “tout en 775 partout” peut sembler raisonnable, puis vous réalisez que des répertoires de cache ou des fichiers de configuration ont été rendus trop modifiables.

Permissions trop fermées

Le blocage est souvent plus visible: erreurs lors de la mise à jour automatique, impossibilité d’éditer un thème ou un plugin via l’interface WordPress, échec de création des répertoires d’uploads, ou erreurs de type “permission denied” dans les logs.

Ce qui complique la résolution, c’est que WordPress peut échouer à écrire sans toujours donner un diagnostic précis. Il peut afficher un message générique, tandis que le vrai signal se trouve dans les logs serveur ou PHP. Sur un site vivant, la bonne pratique est d’identifier quel processus tente d’écrire, et avec quel utilisateur Linux il tourne.

La première règle: identifier l’utilisateur et le groupe utilisés par votre serveur

Avant de modifier quoi que ce soit, vérifiez:

• quel utilisateur possède les fichiers WordPress (par exemple www-data, un utilisateur nommé wordpress, ou ubuntu);
• quel utilisateur exécute PHP (en particulier avec PHP-FPM);
• quel est le groupe associé (souvent lié au mécanisme d’hébergement et aux déploiements).

Sur un hébergement standard, vous aurez souvent un pattern: le serveur web écrit sous le même compte que celui qui lit. Sur des environnements plus “projets”, on voit parfois un utilisateur pour le déploiement (CI/CD), puis un autre pour l’exécution PHP. Dans ce cas, la stratégie de permissions doit être pensée pour permettre l’écriture nécessaire sans ouvrir plus large que prévu.

Si vous ne faites pas cette étape, vous risquez de “réussir” le réglage en apparence, mais de déplacer le problème. Par exemple, vous pouvez rendre les fichiers inscriptibles pour l’utilisateur PHP, donc WordPress casse. Ou au contraire, vous pouvez rendre inscriptibles des éléments qui ne devraient pas l’être.

Cibler les zones d’écriture: uploads, caches, et besoin réel

Dans la logique de permissions de WordPress, les endroits qui doivent être modifiables sont relativement limités. Le reste doit rester majoritairement en lecture seule pour limiter les dégâts.

La réalité opérationnelle est plus nuancée, car les plugins de cache, les outils de compression d’images, ou des thèmes qui génèrent des fichiers peuvent ajouter des besoins d’écriture. Mais vous pouvez raisonner en catégories.

En général, ce qui doit écrire concerne:

• wp-content/uploads pour les médias;
• certains sous-dossiers de wp-content selon les plugins (caches, optimisation, logs locaux si autorisés);
• parfois wp-content/themes et wp-content/plugins si vous éditez via l’interface ou si un processus de déploiement écrit là.

Dans une configuration professionnelle, on évite souvent l’édition directe de code via l’interface WordPress pour les sites sensibles. On privilégie le déploiement via Git, via un pipeline, ou via un système d’automatisation. Résultat: le besoin d’écriture dans themes et plugins devient plus rare. Ce choix simplifie le durcissement des permissions et réduit les risques.

Une stratégie réaliste de durcissement des permissions

Il existe des recettes “tout 755, tout 644” qui peuvent marcher sur un environnement précis, mais l’approche “professionnelle” consiste à appliquer un principe de minimisation des droits, puis à corriger au cas par cas selon l’observation.

L’idée est simple: garder les fichiers en lecture seule et les dossiers en exécution (pour le traversing), n’accorder l’écriture qu’aux dossiers où elle est réellement nécessaire.

Voici un schéma de pensée utile sur la plupart des serveurs Linux:

• fichiers: lecture pour le monde qui doit lire, écriture uniquement pour le propriétaire ou le groupe autorisé;
• dossiers: exécution pour permettre l’accès, écriture uniquement dans les zones d’uploads et les caches.

Ce raisonnement marche bien si vous contrôlez le propriétaire et le groupe. Si ce n’est pas le cas, l’ajustement se fait avec un minimum de changements, et surtout avec vérification.

Appliquer les bons droits sans casser WordPress

Pour passer de la théorie à l’action, il faut une démarche progressive. J’ai appris à ne pas “re-chmod” toute l’arborescence à l’aveugle sur un site en production, surtout sur des hébergements partagés ou sur des volumes montés avec des options spécifiques.

La meilleure méthode consiste à inspecter d’abord, puis à corriger les points sensibles.

Checklist de terrain avant modification

• Vérifier l’utilisateur PHP (PHP-FPM) et l’utilisateur du serveur web
• Contrôler le propriétaire et le groupe actuels des répertoires wp-content et des fichiers clés
• Repérer les dossiers qui doivent écrire (uploads et caches du site)
• Surveiller les logs d’erreur PHP ou du serveur web pour trouver l’utilisateur réellement en cause
• Appliquer un changement ciblé, puis tester l’upload, la mise à jour, et l’édition si elle est autorisée

Cette séquence évite la majorité des “brutefixes” qui finissent par rendre le site inutilisable.

Exemples concrets de réglages: ce que vous pouvez attendre

Sans connaître votre hébergement, je ne peux pas vous donner une valeur unique qui marchera partout, mais je peux décrire les attentes typiques.

Sur beaucoup de configurations standard, les fichiers sont plutôt en mode lecture seul pour le serveur web, et les dossiers en mode traversable. Les uploads, eux, doivent rester inscriptibles.

Une approche fréquente:

• fichiers: un mode autour de 644 (lecture seule, écriture pour le propriétaire);
• dossiers: un mode autour de 755 (accès et traversée, écriture uniquement si nécessaire);
• uploads: un mode qui autorise l’écriture pour l’utilisateur PHP, souvent 775 ou équivalent si vous utilisez un groupe partagé.

Le détail crucial, c’est le “pour qui”. Donner 775 à un dossier n’est pas forcément risqué si le groupe est précisément celui du serveur web, et si les autres n’ont pas l’écriture. En revanche, si vous utilisez 777, vous désactivez de facto une couche de protection, et vous rendez un dépôt de fichier bien plus simple en cas de compromission partielle.

J’ai déjà vu des équipes qui choisissent 777 pour “stabiliser” en production. Ça marche parfois, jusqu’au jour où un plugin commence à écrire davantage, et où une autre vulnérabilité devient exploitable car tout devient modifiable. Ce type de “stabilité” est trompeur.

Gestion des déploiements: propriétaire, groupe, et setgid

Sur un site professionnel, le problème se déplace souvent vers le déploiement. Si vous déployez via CI/CD, vos fichiers arrivent avec un propriétaire et parfois un groupe liés au runner. Ensuite, le serveur web exécute PHP avec un autre utilisateur. Résultat: WordPress ne peut plus écrire, et les mises à jour échouent.

Deux solutions existent généralement, et elles ne se valent pas toutes:

1) Alignement des propriétaires lors du déploiement (le CI dépose sous le bon utilisateur). 2) Stratégie de groupes avec un mécanisme qui force l’appartenance aux fichiers nouvellement créés.

Le mécanisme le plus utile ici est le bit setgid sur les dossiers. Quand il est activé sur un répertoire, les nouveaux fichiers créés à l’intérieur héritent du groupe du dossier, plutôt que de celui du processus. Concrètement, cela permet de maintenir une cohérence “groupe partagé” pour wp-content/uploads et parfois wp-content.

Ce réglage réduit les incidents où un déploiement change le groupe, puis où l’écriture cesse.

Le piège: si vous appliquez setgid à trop de dossiers, vous pouvez aussi accélérer la diffusion de mauvais groupes. Là encore, on cible.

Le cas particulier de wp-config.php et des clés sensibles

wp-config.php est un fichier central. Il contient des identifiants et parfois des constantes sensibles. L’objectif est de limiter strictement l’écriture et, au minimum, d’éviter toute modification par un processus qui n’en a pas besoin.

Même quand le site fonctionne, vérifiez que ce fichier n’est pas modifiable par un groupe large. La lecture doit être possible pour l’utilisateur PHP. L’écriture doit rester limitée au propriétaire que vous contrôlez, idéalement.

C’est aussi un bon moment pour examiner la configuration de votre serveur web côté règles d’accès. Les permissions OS seules ne suffisent pas si le serveur est mal configuré, par exemple si des fichiers sensibles peuvent être servis directement. Mais c’est un autre volet, à traiter avec prudence, sans supposer que “les permissions feront tout”.

Les symptômes qui indiquent un problème de permissions

Sur un site WordPress, les symptômes sont souvent “légers” au début:

• l’éditeur affiche “désolé, vous n’avez pas l’autorisation” alors que vous êtes administrateur;
• l’upload d’images échoue aléatoirement;
• des mises à jour de plugins échouent, puis vous voyez des traces de “permission denied”;
• le site semble fonctionner, puis une tâche planifiée échoue après une modification de droits ou un déploiement.

Quand vous observez ce genre de comportement, pensez “changement récent”: mise à jour du système, changement d’utilisateur PHP-FPM, nouveau déploiement CI/CD, migration d’hébergement, restauration de sauvegarde qui a réappliqué des propriétaires.

Mon réflexe est de relier l’incident à un événement daté. Souvent, le problème de permissions est né exactement au moment où les fichiers ont été créés à nouveau, avec des propriétaires différents.

Une approche pragmatique si WordPress est déjà en place

Si votre site tourne déjà et que vous n’avez pas l’intention de changer d’architecture, vous pouvez durcir progressivement. L’idée est d’éviter la grosse opération “sur tout le disque”.

Commencez par les zones les plus sensibles:

• vérifier wp-config.php et s’assurer qu’il est en mode lecture seule pour le serveur web, écriture réservée à un utilisateur de confiance;
• vérifier les permissions de wp-content/uploads;
• vérifier les répertoires de cache utilisés par vos plugins (sans casser leur fonctionnement).

Ensuite, observez. Si le site continue à fonctionner, vous gagnez une base solide. Si un plugin échoue, vous identifiez précisément quel dossier il essaie d’écrire. Vous corrigez le dossier ciblé, pas l’ensemble.

C’est plus lent sur le papier, mais beaucoup plus rapide au final, parce que vous réduisez les cycles “ça casse, on revient en arrière”.

L’écueil des “recettes” qui ignorent l’environnement

Les recettes de chmod circulent beaucoup, et parfois elles donnent l’impression de résoudre tout. Le problème, c’est que WordPress s’exécute dans un environnement réel, avec des contraintes qui ne sont pas visibles depuis une discussion.

Quelques variables qui changent les résultats:

• PHP-FPM versus mod_php;
• présence de reverse proxy et utilisateurs distincts;
• mode de déploiement (copie simple, rsync avec options, archive extraite);
• systèmes de fichiers avec ACL ou montages spécifiques;
• utilisation de conteneurs ou de volumes partagés.

Dans ce contexte, le bon réglage se valide toujours par test fonctionnel: upload d’image, enregistrement d’un brouillon, mise à jour d’un plugin. Les permissions sont un mécanisme d’accès. Tant que WordPress n’a pas réellement tenté l’écriture, vous ne savez pas si vous êtes juste.

Concilier sécurité et maintenance: la règle du “juste assez”

En sécurité, le “trop” et le “pas assez” se voient rapidement dans le quotidien de l’équipe, mais le coût n’est pas le même.

• Trop restrictif: l’équipe perd du temps, le support augmente, et on finit par rouvrir largement “pour que ça marche”.
• Trop permissif: la surface d’attaque grandit et des scénarios d’écriture non autorisés deviennent possibles.

La posture la plus saine consiste à accepter qu’il y a un minimum de maintenance. Par exemple, si un plugin exige l’écriture dans un dossier, vous acceptez l’écriture dans ce dossier, mais vous refusez l’écriture partout.

Et si vous suivez un modèle DevOps, vous pouvez même réduire la maintenance WordPress “interactive”. En limitant l’édition via interface et en appliquant des déploiements contrôlés, vous rendez le besoin d’écriture moins fréquent. C’est un choix de sécurité, pas un caprice.

Exemple de réglage cible pour uploads et cohérence de groupe

Sur un site où uploads doit écrire, vous voulez que le serveur web puisse écrire, sans donner l’écriture inutile aux autres.

Une stratégie typique est de:

• définir un groupe commun entre le processus PHP et le propriétaire logique du déploiement;
• activer setgid sur wp-content/uploads pour que les fichiers créés héritent du groupe;
• limiter les droits d’écriture aux dossiers qui doivent réellement recevoir des fichiers.

Cela améliore la stabilité après les déploiements, parce que les nouveaux fichiers gardent une appartenance cohérente.

Le point d’attention: si vous activez setgid, vérifiez aussi la cohérence sur les sous-dossiers et que vos outils de sauvegarde ne restaurent pas avec des propriétaires incohérents.

Deux erreurs que j’ai vues, encore et encore

La première erreur: appliquer un même niveau de permissions à tout wp-content sans distinguer uploads, thèmes et caches. Cela donne parfois un site “stable”, puis un plugin de cache ou un outil d’optimisation commence à écrire dans un dossier inattendu. À ce moment-là, une mise à jour ou un changement de plugin peut déclencher un incident.

La seconde erreur: changer les permissions en production sans vérifier l’impact sur les processus en cours. Un chmod pendant qu’un traitement d’upload tourne ou qu’une tâche cron génère des images peut créer des fichiers avec des droits imprévus. Au lieu de “corriger”, vous installez un problème durable, parce que les nouveaux fichiers garderont la mauvaise configuration.

Quand vous ajustez, faites-le dans une fenêtre de maintenance si possible, ou au minimum testez tout de suite après avec des actions qui déclenchent réellement l’écriture.

Vérifier sans deviner: tests simples qui valent de l’or

Vous n’avez pas besoin de lancer un audit compliqué pour valider une configuration de permissions. Les meilleurs tests sont ceux qui couvrent le flux d’écriture réel.

Sur un site WordPress professionnel, un test minimal doit vérifier que les écritures autorisées fonctionnent et que les écritures non attendues échouent. Sans tomber dans les tests invasifs.

Si vous voulez une mini séquence, elle tient en quelques actions concrètes:

• uploader une image et vérifier qu’elle apparaît dans la médiathèque;
• créer un brouillon, puis l’enregistrer;
• exécuter une mise à jour plugin ou thème (celle que vous pouvez lancer sans risque).

Si l’une de ces étapes échoue, vous avez un signal direct. Sinon, vous avez au moins une preuve fonctionnelle que les permissions essentielles sont correctes.

Mini check d’après modification

• Upload et suppression d’un fichier image dans uploads
• Création et enregistrement d’un brouillon dans WordPress
• Vérification du bon comportement des mises à jour (au moins une)

C’est court, mais c’est le genre de contrôle qui évite de “croire” que les permissions sont correctes.

Et si ça ne marche pas malgré tout ?

Quand un ajustement échoue, ne cherchez pas une valeur magique de chmod. Cherchez l’écart entre ce que vous pensez être autorisé, et ce que le système tente réellement de faire.

Les pistes utiles sont:

• regarder les logs d’erreur du serveur web et de PHP;
• repérer le message exact, souvent du style “failed to open stream” ou “permission denied”;
• identifier le chemin du dossier ou du fichier concerné.

Souvent, le problème est un dossier de plugin ou un répertoire de cache non prévu, ou un propriétaire qui a changé après restauration.

Une autre situation que j’ai rencontrée: des ACL (Access Control Lists) héritées d’un ancien système. Dans ce cas, les modes “chmod classiques” ne suffisent pas à expliquer le comportement. Si votre hébergeur utilise des ACL, vous devez raisonner aussi en ACL, pas seulement en mode. Là, l’approche “chmod 755 partout” ne donne pas la réponse.

Le point d’équilibre final

Configurer correctement les permissions sur WordPress, ce n’est pas viser une valeur unique. C’est construire un système cohérent autour de votre architecture: utilisateur PHP, répertoires d’écriture réels, déploiements, et plugins installés.

Une sécurité site WordPress professionnel passe par cette discipline. Vous réduisez les droits d’écriture là où ils ne servent pas, vous donnez les droits https://gardewp.fr/securite-wordpress/ là où WordPress et vos outils ont besoin d’écrire, et vous validez par des tests concrets.

Si vous faites ça, vous gagnez deux choses à la fois: un site plus résistant en cas de problème applicatif, et une équipe qui ne passe pas ses nuits à résoudre des erreurs d’autorisation après chaque mise à jour.

Si vous me décrivez votre contexte (hébergement, Apache ou Nginx, PHP-FPM ou non, et votre méthode de déploiement), je peux vous proposer une cible de permissions plus précise, adaptée à votre arborescence et à vos besoins d’écriture.