Une erreur 403, une mise à jour WordPress bloquée, un plugin qui refuse de s’installer : dans 80 % des cas, la cause est identique. Les permissions fichiers WordPress sont mal configurées. Ce problème silencieux expose votre site à des failles de sécurité et bloque des fonctionnalités critiques sans jamais afficher un message clair. Ce guide vous donne les commandes exactes, les valeurs correctes par contexte d’hébergement et les réflexes pour ne plus jamais subir cette situation.
A lire aussi : WordPress 7.0 : Évolutions Sécurité et Performances Clés
Ce qu’il faut retenir :
- Les permissions idéales sont 755 pour les dossiers et 644 pour les fichiers, sans exception.
- wp-config.php doit être réglé à 440 ou 400 pour bloquer tout accès non autorisé.
- Sur hébergement mutualisé, le propriétaire des fichiers doit correspondre à votre utilisateur FTP.
- Les permissions ne changent pas seules : un plugin mal codé ou un script de déploiement en est souvent responsable.
- Une commande SSH unique permet de tout corriger en moins de 30 secondes sur un serveur dédié.
Comprendre les permissions fichiers WordPress
Sous Linux, chaque fichier et chaque dossier possède trois niveaux de droits : propriétaire (owner), groupe (group) et autres (others). Chaque niveau cumule trois autorisations : lire (4), écrire (2), exécuter (1). On additionne ces valeurs pour obtenir un chiffre entre 0 et 7. Un dossier à 755 signifie : le propriétaire peut tout faire (7), le groupe peut lire et exécuter (5), les autres aussi (5).
WordPress a besoin de lire ses fichiers PHP, d’écrire dans wp-content pour les uploads et les mises à jour, mais jamais d’autoriser le monde entier à modifier vos fichiers core. Le tableau ci-dessous résume les valeurs correctes selon le type d’élément.
| Élément | Permission correcte | Risque si trop ouvert |
|---|---|---|
| Dossiers WordPress | 755 | Écriture non autorisée par des tiers |
| Fichiers PHP/JS/CSS | 644 | Modification de code malveillant |
| wp-config.php | 440 ou 400 | Exposition des identifiants de base de données |
| Dossier wp-content/uploads | 755 | Upload de fichiers exécutables par des attaquants |
| .htaccess | 644 | Redirection malveillante du trafic |
Attention : Régler un fichier à 777 (lecture, écriture et exécution pour tous) est une erreur critique. Cette valeur est parfois suggérée pour « débloquer » rapidement un problème, mais elle ouvre la porte à l’injection de code. Ne l’utilisez jamais en production.
Permissions dossiers WordPress sur hébergement mutualisé
Sur un hébergement mutualisé (OVH, o2switch, Infomaniak…), le serveur web (Apache ou LiteSpeed) tourne souvent sous le même utilisateur que votre compte FTP. Dans ce cas, WordPress peut écrire dans ses propres dossiers sans passer par le groupe ou les autres. Les permissions 755/644 restent la règle, mais le propriétaire doit absolument être votre utilisateur FTP, pas www-data.
Pour vérifier le propriétaire de vos fichiers via SSH :
ls -la /home/votreuser/public_html/
Si vous voyez www-data ou nobody comme propriétaire, contactez votre hébergeur pour un rechown ou corrigez-le avec :
chown -R votreuser:votreuser /home/votreuser/public_html/
Corriger les permissions via SSH sans risque
SSH est la méthode la plus fiable pour corriger les permissions fichiers WordPress en masse. Deux commandes suffisent pour remettre d’aplomb l’intégralité d’une installation, quelle que soit sa taille.
Corriger tous les dossiers en 755 :
find /var/www/html -type d -exec chmod 755 {} ;
Corriger tous les fichiers en 644 :
find /var/www/html -type f -exec chmod 644 {} ;
Remplacez /var/www/html par le chemin réel de votre installation. Sur certains hébergeurs, ce sera /home/user/public_html ou /srv/www/htdocs.
Une fois ces deux commandes exécutées, sécurisez wp-config.php séparément :
chmod 440 /var/www/html/wp-config.php
Conseil : Si vous gérez plusieurs sites WordPress, créez un script shell qui enchaîne ces trois commandes. Stockez-le dans
/usr/local/bin/fix-wp-permset appelez-le en une seule ligne après chaque déploiement. Vous éviterez 90 % des erreurs de permissions post-mise à jour.
Quelles permissions pour wp-config.php en 2026 ?
La question revient régulièrement. En 2026, la recommandation officielle de l’équipe WordPress Security Team reste inchangée : 440 (lecture seule pour le propriétaire et le groupe) ou 400 (lecture seule pour le propriétaire uniquement). La valeur 400 est préférable sur un VPS ou serveur dédié où vous contrôlez totalement l’utilisateur du serveur web. Sur mutualisé, 440 est souvent nécessaire pour que PHP puisse lire le fichier.
wp-config.php contient vos identifiants de base de données, les clés secrètes et le préfixe de table. Un accès en lecture depuis le web à ce fichier compromet l’intégralité de votre site. Si vous effectuez un audit WordPress, ce fichier est systématiquement le premier point de contrôle.
Pourquoi les permissions changent-elles toutes seules ?
C’est une question fréquente. Trois causes expliquent ce phénomène :
- Un plugin de mise à jour automatique qui recrée des fichiers avec les permissions par défaut de l’utilisateur PHP (souvent 664 ou 666).
- Un script de déploiement (Git, Capistrano, WP-CLI) mal configuré qui n’applique pas de umask correct.
- Un hébergeur qui applique périodiquement une politique de sécurité et réinitialise les permissions à des valeurs standards (parfois trop restrictives).
Pour diagnostiquer l’origine, comparez les dates de modification des fichiers avec les logs d’accès de votre panneau de contrôle. Si les changements coïncident avec des mises à jour automatiques, désactivez-les et gérez-les manuellement, ou explorez les meilleurs plugins IA pour la maintenance et la sécurité WordPress en 2026 qui incluent des vérifications de permissions en temps réel.
A lire aussi : Collaboration en temps réel dans WordPress 7 : fini le travail solo !
Cas particulier : WordPress multisite
Un réseau multisite WordPress ajoute une couche de complexité. Le dossier wp-content/blogs.dir (ancienne architecture) ou les sous-dossiers dans wp-content/uploads/sites/ (nouvelle architecture) doivent être accessibles en écriture par le serveur web. Appliquez 775 sur ces dossiers si l’utilisateur du serveur web est différent du propriétaire des fichiers, et 755 si c’est le même utilisateur. Ne montez jamais à 777.
Sécuriser les fichiers WordPress au-delà des permissions
Les permissions fichiers WordPress sont un pilier, mais la sécurisation ne s’arrête pas là. Voici les actions complémentaires qui font réellement la différence.
Protéger wp-config.php via .htaccess
En plus du chmod, ajoutez ce bloc dans votre fichier .htaccess à la racine pour bloquer tout accès HTTP direct :
<Files wp-config.php>
order allow,deny
deny from all
</Files>
Cette règle fonctionne sur Apache et LiteSpeed. Sur Nginx, l’équivalent se place dans le bloc server de votre configuration vhost.
Vérification automatique des permissions avec WP-CLI
WP-CLI et les nouveaux protocoles d’automatisation WordPress permettent d’intégrer des vérifications de permissions dans vos pipelines CI/CD. La commande wp core verify-checksums contrôle l’intégrité des fichiers core, mais ne vérifie pas les permissions. Combinez-la avec un script bash personnalisé pour une vérification complète à chaque déploiement.
Impact SEO d’une mauvaise configuration
Une erreur de permissions peut bloquer la génération du sitemap XML, empêcher la mise en cache ou rendre inaccessibles certaines pages. Googlebot retourne alors des erreurs 403 ou 500 qui dégradent directement votre indexation. Si vous constatez une chute soudaine de trafic organique, vérifiez les permissions de wp-content/cache et du dossier du plugin SEO avant toute autre investigation. Pour aller plus loin sur l’optimisation technique, consultez le guide sur AI SEO et optimisation des images WordPress en 2026.
En résumé, les permissions fichiers WordPress se corrigent en quelques minutes avec les bonnes commandes, mais leur surveillance doit être continue. Un site mal configuré accumule silencieusement des vulnérabilités que les scanners automatisés exploitent en quelques heures. Appliquez les valeurs 755/644, sécurisez wp-config.php à 440, vérifiez le propriétaire des fichiers et automatisez ces contrôles. Votre site sera plus stable, plus sûr et mieux indexé.
FAQ : permissions fichiers WordPress
Quelles permissions pour wp-config.php en 2026 ?
La valeur recommandée est 440 sur hébergement mutualisé et 400 sur serveur dédié ou VPS. Ces réglages limitent la lecture au seul propriétaire (et au groupe sur mutualisé) et interdisent toute écriture ou exécution. Protégez aussi ce fichier via une règle .htaccess qui bloque l’accès HTTP direct.
Comment corriger les permissions via SSH sans risque ?
Utilisez la commande find avec l’option -type d pour les dossiers (chmod 755) et -type f pour les fichiers (chmod 644). Testez d’abord sur un environnement de staging. N’utilisez jamais de chmod récursif avec -R 777 : cette commande règle tout en écriture totale et crée une faille immédiate.
Pourquoi mes permissions changent-elles toutes seules ?
Les coupables habituels sont les plugins de mise à jour automatique, les scripts de déploiement sans umask configuré et les politiques de sécurité appliquées par certains hébergeurs. Analysez les logs d’accès pour corréler les changements de permissions avec des événements précis sur votre serveur.
Quelles sont les permissions idéales sur hébergement mutualisé ?
Sur mutualisé, 755 pour les dossiers et 644 pour les fichiers restent la norme. Le point critique est le propriétaire des fichiers : il doit correspondre à votre utilisateur FTP ou cPanel. Si le propriétaire est www-data ou nobody, WordPress ne pourra pas écrire lors des mises à jour et affichera des erreurs de permissions.
Une mauvaise permission peut-elle nuire au SEO ?
Oui. Une permission trop restrictive sur le dossier de cache ou le répertoire d’un plugin SEO peut provoquer des erreurs 403 que Googlebot enregistre. Si ces erreurs touchent des URLs indexées, elles peuvent entraîner une désindexation partielle. Vérifiez la compatibilité avec les nouvelles fonctionnalités WordPress 7 qui incluent des outils de diagnostic intégrés pour détecter ces problèmes.
