Les permissions fichiers d’un site WordPress sont le réglage de sécurité le plus discret et l’un des plus efficaces. Bien configurées, elles empêchent un attaquant qui aurait trouvé une faille dans un plugin de remonter jusqu’au cœur du site, d’écrire de nouveaux fichiers malveillants, ou de lire les identifiants de la base de données. Mal configurées (souvent en 777 pour faire fonctionner un plugin capricieux), elles ouvrent grand la porte à toutes les escalades de privilèges. Pourtant le sujet reste mystérieux pour beaucoup d’entrepreneurs : codes à trois chiffres, terminologie Unix, distinctions entre dossiers et fichiers. Chez Propuls’Lead, nous appliquons un schéma standard de permissions sur tous les sites WordPress de nos clients et nous vérifions ce schéma trimestriellement, parce qu’un site qui passe en 777 pour résoudre un problème ponctuel n’est presque jamais remis en sécurité ensuite.
Comprendre la grammaire des permissions Unix appliquée à WordPress
Les permissions Unix se notent avec trois chiffres entre 0 et 7, par exemple 644 ou 755. Chaque chiffre correspond à une catégorie : le propriétaire du fichier, le groupe associé, et tout autre utilisateur (incluant les visiteurs anonymes). La valeur est la somme de trois droits : 4 pour la lecture, 2 pour l’écriture, 1 pour l’exécution.
Une valeur de 6 signifie lecture plus écriture sans exécution. Une valeur de 5 signifie lecture plus exécution sans écriture. Une valeur de 7 cumule les trois droits. Le code 644 donne propriétaire en lecture-écriture, groupe en lecture, autres en lecture. Le code 755 ajoute l’exécution pour les trois catégories.
Sur un serveur web, le processus PHP qui exécute WordPress tourne avec un utilisateur Unix particulier (typiquement www-data sur Debian, apache sur CentOS, ou un utilisateur dédié au client sur les hébergements mutualisés). Cet utilisateur doit avoir les droits nécessaires pour faire fonctionner WordPress sans donner trop de droits aux « autres ». Notre article sur sécuriser son site WordPress avec les 10 actions qui bloquent 99 % des attaques revient sur les réglages serveur qui complètent les permissions.
Appliquer les valeurs recommandées pour les dossiers et les fichiers
WordPress.org recommande un schéma standard qui couvre la majorité des installations. Les dossiers reçoivent 755 : le propriétaire peut tout faire, les autres peuvent lire et traverser le dossier mais ne peuvent pas y écrire. Les fichiers reçoivent 644 : le propriétaire peut lire et écrire, les autres peuvent seulement lire. Ce schéma laisse à WordPress la possibilité de fonctionner normalement (lecture des fichiers PHP, écriture dans les uploads via le propriétaire) tout en empêchant un visiteur anonyme d’écrire des fichiers.
Trois fichiers méritent un traitement spécifique. Le fichier wp-config.php contient les identifiants de la base de données et la clé d’authentification du site. Sa permission recommandée est 600 ou 640 : seul le propriétaire peut le lire, personne d’autre. Cette permission empêche un attaquant ayant accédé au serveur via un autre site mutualisé de lire les identifiants WordPress. Le fichier .htaccess gère les règles de réécriture d’URL et les protections d’accès : permission 644 standard, mais une protection supplémentaire interdit aux visiteurs de modifier ce fichier via l’interface WordPress.
Le dossier wp-content/uploads pose une question particulière : WordPress doit pouvoir y écrire pour téléverser les médias, mais aucun fichier PHP ne doit pouvoir y être exécuté. La solution se trouve dans le .htaccess placé à la racine de uploads qui interdit l’exécution PHP : sans cette règle, un attaquant qui téléverserait un script PHP malveillant via une faille pourrait l’exécuter en y accédant directement par URL. Notre article sur protéger sa page de connexion WordPress contre les attaques par force brute revient sur le couple permissions-authentification qui ferme la porte d’entrée.
Appliquer les permissions correctes via FTP ou ligne de commande
L’application en pratique se fait via deux outils principaux. Premier outil : un client FTP comme FileZilla ou Cyberduck. La modification se fait par clic droit sur le fichier ou dossier, puis « Permissions du fichier » ou « chmod » dans le menu contextuel. L’outil affiche les trois chiffres et permet de les modifier soit par cases à cocher, soit en saisissant directement la valeur numérique.
Deuxième outil : la ligne de commande SSH pour les utilisateurs à l’aise techniquement. Deux commandes permettent d’appliquer le schéma standard sur tout un site en quelques secondes. La commande find /chemin/du/site -type d -exec chmod 755 {} + applique 755 à tous les dossiers récursivement. La commande find /chemin/du/site -type f -exec chmod 644 {} + applique 644 à tous les fichiers récursivement. Une troisième commande, chmod 600 wp-config.php, durcit le fichier critique.
Beaucoup d’hébergeurs mutualisés (OVH, o2switch, Infomaniak en France) proposent aussi un outil graphique de gestion des permissions dans leur back-office, ce qui évite l’usage du FTP ou du SSH pour les opérations courantes. La vérification trimestrielle prend cinq minutes et garantit qu’aucun fichier n’est revenu à des valeurs trop permissives suite à une intervention. Notre article sur WordPress et l’hébergement, passer du mutualisé au VPS revient sur les choix d’hébergement qui conditionnent les outils disponibles.
Éviter le piège du 777 et gérer les plugins capricieux
L’erreur la plus fréquente et la plus dangereuse consiste à passer un fichier ou un dossier en 777 pour faire fonctionner un plugin qui demande des « droits d’écriture ». Le code 777 donne tous les droits à tout le monde, y compris l’exécution par n’importe quel utilisateur du serveur. Sur un hébergement mutualisé, un attaquant ayant compromis un autre site sur le même serveur peut alors écrire dans votre installation WordPress.
La règle d’or : ne jamais passer un fichier ou dossier en 777, même temporairement. Si un plugin demande des droits d’écriture, vérifier que l’utilisateur PHP est bien le propriétaire des fichiers et que ces fichiers sont en 644 (avec dossiers en 755). Dans 99 % des cas, le problème vient d’un décalage entre l’utilisateur propriétaire et l’utilisateur PHP, pas d’un manque de droits intrinsèque.
Si le problème persiste, contacter le support de l’hébergeur pour corriger le décalage. Aucun plugin sérieux ne nécessite du 777 pour fonctionner. Si un plugin l’exige absolument, c’est un signal d’alarme sur la qualité du plugin : le désinstaller et chercher une alternative est la meilleure réponse. Notre article sur WordPress et les sauvegardes automatiques revient sur le filet de sécurité qui réduit la dépendance à des plugins risqués.
Industrialiser la vérification dans la méthodologie PROPULSE
Dans le cadre de la méthodologie PROPULSE que nous appliquons chez Propuls’Lead, la gestion des permissions WordPress suit un protocole en trois temps. À la mise en ligne du site, le schéma standard est appliqué via une commande SSH unique qui couvre l’ensemble des dossiers et fichiers : 755 pour les dossiers, 644 pour les fichiers, 600 pour wp-config.php, plus la règle .htaccess qui interdit l’exécution PHP dans uploads.
Chaque trimestre, un audit automatisé vérifie via un script SSH que les permissions n’ont pas dérivé. Le script détecte tout fichier ou dossier en 777, tout wp-config.php repassé en 644, tout fichier PHP créé dans uploads. Le rapport est généré automatiquement et envoyé au consultant en charge du site, qui corrige le cas échéant. Cette industrialisation prend dix minutes par trimestre et par site.
Sur les sites que nous accompagnons depuis plusieurs années, ce protocole a empêché plusieurs tentatives d’escalade post-intrusion : les attaquants n’ont pas pu écrire les fichiers nécessaires à leur prise de contrôle, et l’intrusion s’est limitée à un événement annulable par sauvegarde. Notre article sur Wordfence vs Sucuri, quel plugin de sécurité WordPress choisir pour une PME revient sur le couple permissions-pare-feu qui forme la défense en profondeur.
Ce qu’il faut retenir pour configurer les permissions fichiers WordPress
Les permissions fichiers sont un réglage discret et l’un des plus protecteurs sur WordPress. Cinq points clés à retenir : la grammaire chmod combine lecture écriture et exécution sur trois catégories propriétaire groupe autres, le schéma standard 755 pour les dossiers et 644 pour les fichiers couvre la majorité des cas, wp-config.php mérite un traitement en 600 ou 640 pour protéger les identifiants de base de données, le dossier uploads doit interdire l’exécution PHP via une règle htaccess dédiée, le code 777 est à proscrire absolument même temporairement. Chez Propuls’Lead, l’application systématique de ce schéma ferme une porte d’entrée souvent négligée mais largement exploitée.