Sécuriser WordPress : corriger les permissions de fichiers

Quand WordPress fonctionne bien, on y pense à peine. Le jour où un plugin ne peut plus écrire dans le dossier des médias, que l’installation échoue, ou que la mise à jour refuse avec des erreurs du type “impossible d’écrire”, on réalise vite que les permissions de fichiers ne sont pas une formalité. Elles servent à deux choses à la fois: garantir le bon fonctionnement (écriture là où il faut) et limiter ce que le serveur autorise à modifier (réduction des dégâts en cas de problème).

Dans la pratique, corriger les permissions est souvent un compromis. https://gardewp.fr/securite-wordpress/ Trop permissif, vous augmentez la surface d’attaque. Trop restrictif, vous cassez l’administration, les mises à jour, l’upload, parfois même le cache. Le bon réglage dépend de votre hébergement, de votre architecture (Apache, Nginx, PHP-FPM, mode FPM pool), et de la façon dont le compte utilisateur exécute PHP.

Je vais vous guider avec une logique simple, des exemples concrets, et des garde-fous. L’objectif n’est pas de viser un “chiffre magique”, mais de comprendre ce que signifient réellement les permissions et de les remettre dans un état cohérent.

Permissions, propriétaire et droits d’accès: la pièce manquante

Avant de “chiffrer” ou lancer un chmod au hasard, il faut distinguer trois notions qui se mélangent trop souvent:

le propriétaire du fichier (un utilisateur, par exemple www-data ou apache) le groupe associé (souvent le même compte ou un groupe dédié) les droits eux-mêmes (lecture, écriture, exécution) pour le propriétaire, le groupe, et le reste du monde

Sur un système Linux, un affichage du type:

Ls -l

Donne des informations comme -rw-r--r-- ou drwxr-xr-x, puis le propriétaire, le groupe, la taille, et la date.

En langage “permissions”:

lecture autorise la consultation écriture autorise la modification exécution autorise l’accès en tant que programme ou, pour les dossiers, le passage dans l’arborescence

Pour WordPress, la grande question est toujours la même: quel utilisateur PHP doit pouvoir écrire, et dans quels dossiers.

Un exemple typique: le dossier wp-content/uploads doit accepter l’écriture par le processus PHP, parce que WordPress y stocke les images et documents. En revanche, des fichiers comme wp-config.php ne doivent pas être modifiables par “tout le monde”.

Les erreurs fréquentes: trop large, pas assez cohérent

On voit souvent deux extrêmes.

Le premier est trop large: des permissions “tout le monde peut écrire” (777 en pratique). C’est parfois fait rapidement “pour que ça marche”. Le résultat peut tenir quelque temps, puis s’avérer dangereux, car un problème applicatif ou une compromission pourrait écrire ou altérer des fichiers qui ne devraient pas être modifiables.

Le second est trop strict, souvent une correction “à l’aveugle” après un incident. Si vous passez tout en lecture seule, WordPress peut afficher une page, mais casser l’administration, les mises à jour, ou l’upload. Les erreurs ne sont pas toujours immédiates: certaines actions échouent seulement au moment d’écrire, par exemple lors de la création du cache, de l’installation d’un plugin, ou de la régénération de vignettes.

Le piège que je rencontre le plus souvent: la permission semble correcte en valeur, mais le propriétaire ou le groupe ne correspond pas au compte qui exécute PHP. Dans ce cas, changer chmod ne suffit pas. Il faut aussi vérifier chown et, selon le mode, le “groupe” (chgrp) utilisé.

Repérer votre contexte d’hébergement

Avant toute modification, prenez 10 minutes pour identifier le contexte. Sans ça, vous risquez de corriger le mauvais compte, donc de “tourner en rond”.

Voici des indices utiles:

Votre mode d’hébergement

Sur mutualisé, vous n’avez pas forcément le même contrôle qu’en VPS ou dédié. En VPS, vous contrôlez plus facilement propriétaire et groupes.

Le compte qui exécute PHP

Sur beaucoup d’installations Linux, on voit www-data ou apache. Sur certains systèmes, c’est un autre utilisateur, parfois spécifique à un pool PHP-FPM.

L’interface dont vous disposez

cPanel, Plesk, interfaces maison: parfois une gestion “permissions” simplifiée. accès SSH: vous pouvez faire des find, stat, chmod, chown proprement.

Si vous avez accès à un fichier de logs et à un message d’erreur précis, exploitez-le. Une erreur “Permission denied” indique le côté OS, pas un problème purement WordPress.

Les permissions “courantes” pour WordPress (et pourquoi elles ne sont pas universelles)

Il n’existe pas une règle unique valable partout. Pourtant, il y a des recommandations courantes, utiles comme point de départ.

En général, on cherche:

des dossiers exécutables (pour permettre de traverser l’arborescence) des fichiers non exécutables (pour limiter l’exécution accidentelle) une écriture limitée aux zones nécessaires

En valeurs usuelles:

dossiers: 755 (lecture et exécution pour les autres, écriture seulement pour le propriétaire) fichiers: 644 (lecture pour tous, écriture seulement pour le propriétaire) wp-config.php: souvent plus restrictif (par exemple 600 ou 640 selon le groupe et votre stratégie) wp-content/uploads: souvent plus permissif sur l’écriture, typiquement 755 ou 775 selon le groupe PHP, pour permettre l’upload sans ouvrir au monde

Le point important: si votre serveur PHP s’exécute sous un groupe différent du propriétaire, 775 peut être plus correct que 755 (car il donne l’écriture au groupe, pas au monde).

Une règle pratique qui évite les dégâts

Plutôt que de viser “plus” ou “moins”, visez “juste assez” et “aligné sur le compte PHP”.

Dans mon expérience, la majorité des cas se résolvent en deux ajustements:

remettre les dossiers et fichiers sur une base cohérente (par exemple 755 et 644) accorder l’écriture uniquement aux dossiers qui doivent l’être, avec le bon propriétaire ou le bon groupe

Diagnostiquer avant de corriger: trois indices concrets

Quand WordPress refuse de faire une opération, il y a souvent un indice direct.

D’abord, regardez l’erreur WordPress: elle cite parfois “uploads”, “plugins”, “themes”, ou mentionne un fichier précis.

Ensuite, côté serveur, cherchez les logs (selon votre hébergement, vous avez accès à des logs Apache/Nginx, ou à un log PHP). Les messages “Permission denied” contiennent souvent le chemin du fichier et l’utilisateur concerné.

Enfin, côté système, inspectez les permissions actuelles. Sur un dossier critique comme wp-content, faites:

Ls -l wp-content Ls -l wp-content/uploads

Si vous voyez par exemple uploads appartenir à un autre utilisateur que celui qui exécute PHP, ou si des fichiers sont assignés à un propriétaire inattendu (souvent après un upload via FTP sous un autre compte), vous avez trouvé une cause probable.

Corriger les permissions: une méthode prudente

L’approche que je privilégie commence par une “mise à niveau cohérente”, puis une correction ciblée de ce qui doit être modifiable.

Étape 1: sauvegarder, puis cibler

Avant toute commande qui change des droits sur des milliers de fichiers, faites une sauvegarde. Même sur un environnement de test, ça évite de perdre du temps.

Ensuite, identifiez la racine WordPress. Parfois elle n’est pas juste /var/www/html. Sur un VPS, c’est courant que l’arborescence soit différente.

Si vous êtes sûr de votre chemin, vous pouvez appliquer les corrections directement sur la racine WordPress.

Étape 2: remettre une base cohérente (dossiers et fichiers)

Sur un Linux classique, une commande type consiste à donner 755 aux dossiers et 644 aux fichiers. Par exemple:

# Dossiers Find /chemin/vers/wordpress -type d -exec chmod 755 \; # Fichiers Find /chemin/vers/wordpress -type f -exec chmod 644 \;

Je dis “type” parce que la valeur exacte peut changer. Certains hébergeurs recommandent par exemple 750 ou 640 dans des contextes renforcés. Mais la logique reste identique.

Attention: cette approche remet aussi les permissions de wp-config.php et potentiellement de fichiers que vous voulez garder très restrictifs. C’est pour ça qu’on la fait en étape, puis qu’on corrige ensuite.

Étape 3: ajuster le cas particulier de wp-config.php

wp-config.php contient des identifiants. Même si PHP peut s’en servir, l’OS doit éviter que quelqu’un d’autre puisse y accéder ou le modifier.

Une valeur souvent utilisée est 600:

Chmod 600 /chemin/vers/wordpress/wp-config.php

Sur certains serveurs, un mode 640 avec un groupe contrôlé est plus adapté si PHP n’est pas exécuté en tant que propriétaire du fichier. L’enjeu est le même: vous devez garder une lecture pour le processus PHP, tout en retirant l’accès au reste.

Étape 4: donner l’écriture au dossier d’upload uniquement

Ensuite, on traite wp-content/uploads. Selon votre stratégie, vous pouvez rendre ce dossier et son contenu plus permissifs, par exemple en autorisant l’écriture pour le propriétaire et le groupe.

Un schéma fréquent consiste à mettre uploads en 755 ou 775. Par exemple:

Chmod 755 /chemin/vers/wordpress/wp-content/uploads

Puis, si PHP tourne sur le groupe et que vous voulez permettre au groupe d’écrire, vous pouvez préférer 775:

Chmod 775 /chemin/vers/wordpress/wp-content/uploads

Le bon choix dépend d’un détail crucial: le propriétaire et le groupe du dossier.

Étape 5: aligner propriétaire et groupe (souvent le vrai problème)

Si vos permissions “chiffrées” semblent bonnes mais WordPress continue d’échouer, c’est souvent que le propriétaire ne correspond pas.

Pour vérifier:

Ls -l /chemin/vers/wordpress/wp-content/uploads

Si vous voyez un propriétaire différent de ce que PHP utilise, vous devez corriger avec chown et éventuellement chgrp.

Exemple (à adapter, c’est volontairement générique):

Chown -R www-data:www-data /chemin/vers/wordpress/wp-content/uploads

Sur certains systèmes, vous voulez plutôt laisser le propriétaire comme est, et uniquement corriger le groupe. Dans ce cas, vous pourriez faire un chgrp plutôt qu’un chown. Le meilleur réglage dépend de votre politique d’hébergement, et je n’aime pas “deviner” sans voir la config.

Ce que je vérifierais, avant et après: une mini check-list

Voici les vérifications qui évitent 90% des allers-retours:

le processus PHP (compte ou groupe) a le droit d’écrire dans wp-content/uploads wp-config.php n’est pas accessible en écriture par des rôles non nécessaires les dossiers ont l’exécution (x) pour permettre la traversée, sinon WordPress bloque sans message clair après modification, test immédiat: envoi d’un fichier dans la médiathèque et mise à jour d’un plugin (dans un contexte maîtrisé)

Cette check-list n’est pas magique, mais c’est un filtre mental qui rend la démarche rapide.

Un cas particulier: FTP, SFTP et ownership “cassé”

Il m’est arrivé de dépanner des sites où WordPress était “correct”, puis l’upload échouait après un transfert FTP.

Cause typique: le transfert a mis un propriétaire différent sur certains fichiers (ou un mélange de propriétaires dans wp-content/uploads). Sur mutualisé, vous n’avez pas forcément le contrôle de tous les propriétaires. Sur VPS, c’est plus facile à corriger, mais cela demande une discipline.

Si vous voyez des fichiers dans uploads appartenir à un utilisateur qui n’est pas celui du serveur PHP, corriger “au cas par cas” peut être plus long que refaire un alignement sur le dossier uploads.

Dans certains cas, c’est aussi une opportunité d’améliorer votre méthode de déploiement: privilégier SFTP en utilisant le bon utilisateur système, ou un mécanisme cohérent avec votre serveur.

Risques, compromis et “permissions qui marchent” mais ne sécurisent pas

Le piège le plus courant est d’avoir un site qui “fonctionne”, mais qui reste trop exposé.

Trop permissif

Une configuration qui laisse de nombreux fichiers en 666 ou des dossiers en 777 peut fonctionner. Elle facilite aussi les modifications non désirées si un composant est compromis, si une extension mal écrite est exploitée, ou si un attaquant trouve une voie de dépôt de webshell.

Dans une démarche de sécurisation, l’objectif est de limiter l’écriture aux endroits indispensables.

Trop restrictif

Inversement, une configuration trop stricte bloque:

uploads installation ou activation de thèmes et plugins mises à jour automatiques génération de caches, selon les extensions (cache serveur, cache de l’image, minification)

Dans les environnements avec plugins de cache agressifs ou compression, vous verrez souvent des symptômes “bizarres” après une correction excessive. Le cache échoue et le site peut ralentir ou afficher des erreurs intermittentes.

Le bon jugement consiste à ajuster, tester, puis fixer. Les permissions se valident dans la durée, pas juste à l’instant où le message d’erreur disparaît.

Exemple de corrections ciblées selon le type de dossier

Plutôt que de traiter tout WordPress identiquement, on peut raisonner par zone.

| Zone WordPress | Objectif | Permissions souvent visées (principe) | |---|---|---| | dossiers racine et sous-dossiers hors uploads | permettre l’accès aux scripts et la traversée | dossiers avec exécution, écriture limitée | | fichiers PHP de WordPress | exécution par PHP, non modification “au hasard” | fichiers non exécutables en tant que fichier système, écriture restreinte | | wp-content/uploads | écriture pour l’upload | dossier autorisant l’écriture pour le processus PHP | | wp-config.php | lecture par PHP, pas d’accès excessif | très restrictif, idéalement lecture seule pour l’exécution nécessaire |

Les valeurs exactes peuvent varier. Mais le principe structure votre décision, au lieu de vous enfermer dans un chiffre.

Comment éviter de casser des permissions en cascade

Quand vous lancez chmod -R sur un grand ensemble, vous pouvez involontairement modifier aussi des dossiers que votre hébergement utilise pour d’autres besoins (ou des liens symboliques, selon les cas).

Une précaution utile consiste à:

cibler wp-content/uploads et parfois wp-content pour les droits d’écriture limiter la correction globale aux besoins de base faire un test d’upload après chaque “gros” changement

Si vous déployez régulièrement, vous pouvez aussi mettre en place une méthode de déploiement qui conserve le propriétaire et le groupe attendus, au lieu de reposer sur le hasard des transferts.

Si vous êtes sur Windows ou sans SSH: comment raisonner quand chmod ne s’applique pas

Sur Windows, les permissions et l’exécution ne fonctionnent pas sur le même modèle. Les images, la gestion des erreurs et le comportement de PHP peuvent différer. Dans ce cas, la “correction des permissions de fichiers” passe plutôt par:

la bonne configuration du propriétaire côté service (si possible) l’héritage des droits sur les dossiers la configuration de votre environnement web

Je préfère ne pas inventer un équivalent “chmod Windows” parce que ça dépend de votre stack (IIS, WAMP, contrôle d’accès NTFS, etc.). Le raisonnement reste toutefois le même: WordPress doit écrire dans les dossiers attendus, et les fichiers sensibles doivent rester inaccessibles en modification non nécessaire.

Vérifications finales: s’assurer que WordPress utilise bien les droits

Une fois vos droits corrigés, testez sans rester dans l’abstrait.

Essayez d’envoyer une image dans la médiathèque. Si l’upload passe, vous avez déjà corrigé le point le plus sensible. Essayez une mise à jour de plugin ou l’installation d’un thème (si vous l’avez autorisée sur cet environnement). Surveillez les erreurs pendant quelques heures, surtout si un plugin cache ou un service d’optimisation est actif.

Dans une dépanné que j’ai faite récemment, tout était “OK” en apparence, mais un plugin de galerie échouait à régénérer des miniatures. Le site affichait les pages, donc la mission semblait terminée. En réalité, une partie de l’arborescence avait conservé des droits inadaptés. Le test d’upload ne suffit pas toujours, il faut aussi provoquer les actions qui écrivent, comme la régénération ou la mise à jour des assets.

Quand appeler l’aide de l’hébergement

Si vous êtes en mutualisé et que vous n’avez pas la main sur le compte utilisateur PHP, vous pouvez être limité par l’hébergement. Dans ce cas, même avec une correction “théorique”, le serveur peut refuser l’écriture.

Si vos logs montrent un utilisateur non modifiable, ou si le système refuse chown, contactez le support. Demandez explicitement comment PHP est exécuté (compte ou pool) et quels dossiers nécessitent un droit d’écriture côté serveur.

C’est souvent plus rapide que d’essayer 20 variantes de permissions.

En pratique: une stratégie simple pour “sécuriser site WordPress” sans se compliquer la vie

La meilleure approche que j’ai adoptée sur plusieurs sites, blogs et petites boutiques en ligne, tient en trois règles:

Premièrement, partez d’une base cohérente, généralement dossiers en exécution pour que WordPress puisse parcourir, fichiers plus restrictifs.

Deuxièmement, offrez l’écriture uniquement aux zones nécessaires, en particulier wp-content/uploads, et seulement pour le bon compte ou le bon groupe.

Troisièmement, validez par des tests concrets d’administration et d’upload, pas seulement par une impression de conformité.

Avec cette discipline, corriger les permissions devient moins une loterie qu’une petite opération maîtrisée.

Si vous voulez, décrivez votre hébergement (mutualisé ou VPS), votre OS (Linux, Windows) et l’utilisateur PHP si vous le connaissez. Vous pouvez aussi copier le résultat de ls -l sur wp-content et wp-content/uploads (en masquant les noms sensibles). Je pourrai vous proposer un réglage plus précis, adapté à votre cas.