Comment configurer et sécuriser les permissions de fichiers dans WordPress ?

Montrer le sommaire Cacher le sommaire

• Comment repérer vite un problème de permissions sur votre site WordPress
• Quelles permissions appliquer en pratique pour éviter les erreurs courantes
• Comment corriger les permissions sans casser le site et les précautions à prendre
  • Commandes pratiques
• Qui doit posséder les fichiers et quel impact sur la sécurité et les uploads
• Autres protections complémentaires quand chmod ne suffit pas
• Que faire si un malware a modifié vos permissions
• Erreurs courantes que j’ai souvent vues et comment les éviter
• FAQ

Les permissions de fichiers WordPress sont souvent négligées jusqu’au jour où un plugin ne peut plus écrire, qu’un upload échoue ou qu’un pirate prend le contrôle. Bien gérées, elles réduisent les risques et limitent les dégâts ; mal réglées, elles transforment une petite vulnérabilité en brèche durable. Voici des conseils pratiques, des erreurs fréquentes et des actions concrètes pour que vos fichiers et dossiers restent fonctionnels et sûrs.

Comment repérer vite un problème de permissions sur votre site WordPress

Plusieurs indices vous avertissent qu’il y a un souci : erreurs 500, écriture impossible dans wp-content/uploads, échecs d’installation de plugins, page blanche (white screen of death) ou fichiers système passés en lecture seule comme index.php ou .htaccess. Parfois le serveur renvoie un message explicite « permission denied » dans les logs.

Vérifiez d’abord les logs Apache/Nginx et PHP. Ensuite contrôlez l’état avec un accès SSH si possible en lançant ls -l à la racine de WordPress. Si vous n’avez que cPanel ou un client FTP vous pouvez aussi y voir les valeurs numériques (0644, 0755, etc.).

Attention aux faux diagnostics : des fichiers en 444 n’indiquent pas toujours une attaque, mais c’est un signal fort à creuser. De même, ne vous contentez pas d’un outil qui « corrige » automatiquement les permissions sans expliquer ce qu’il change.

Quelles permissions appliquer en pratique pour éviter les erreurs courantes

Les valeurs classiques servent de base parce qu’elles équilibrent sécurité et fonctionnement. En règle générale on vise : fichiers 644 et répertoires 755. Mais il existe des exceptions liées à la configuration PHP et à l’hébergement.

Fichier ou dossier	Valeur recommandée	Pourquoi
Fichiers PHP (index.php, .php racine)	644	Lecture par le serveur, écriture réservée au propriétaire
Répertoires (wp-admin, wp-includes, etc.)	755	Permet la navigation dans le dossier sans autoriser l’écriture publique
wp-config.php	600 ou 640 selon l’hôte	Contient les identifiants DB et clés, limiter l’accès au strict nécessaire
.htaccess	644 (ou 640 selon host)	Le serveur doit lire les règles mais l’écriture doit rester restreinte
wp-content/uploads	755	Plugins et WordPress doivent pouvoir créer des fichiers

N’utilisez jamais 777 en production. Cela autorise tout le monde à écrire et facilite nettement l’élévation de privilèges par un script malveillant.

Comment corriger les permissions sans casser le site et les précautions à prendre

Avant toute modification sauvegardez votre site et vos fichiers. Testez sur un environnement de préproduction si possible. Les commandes les plus utiles en SSH sont simples mais puissantes : pour remettre une base saine

Commandes pratiques

Exemples fréquents à adapter selon le chemin et l’utilisateur :

• find /chemin/wordpress -type d -exec chmod 755 {} ; pour les dossiers
• find /chemin/wordpress -type f -exec chmod 644 {} ; pour les fichiers
• chmod 600 /chemin/wordpress/wp-config.php fixer le fichier de config
• chown -R user:webgroup /chemin/wordpress ajuster le propriétaire et le groupe

Ne lancez pas mécaniquement un chmod -R 755 sur toute l’arborescence sans réfléchir. Certains fichiers doivent rester non exécutables et rendre un fichier exécutable inutilement peut créer un vecteur d’attaque.

Qui doit posséder les fichiers et quel impact sur la sécurité et les uploads

Le couple propriétaire/groupe détermine ce que PHP, l’utilisateur SSH ou FTP et d’autres processus peuvent faire. Sur Debian/Ubuntu le serveur web tourne souvent sous www-data, sur CentOS sous apache ou nginx. Si vos fichiers sont possédés par votre utilisateur deploy et que PHP s’exécute sous www-data, WordPress peut ne pas pouvoir écrire dans wp-content.

Cas fréquents observés : un développeur exécute des commandes en root et change ownership à son utilisateur personnel, puis les uploads échouent. Solution simple : harmoniser propriétaire et groupe selon qui doit écrire, ou donner le groupe au user web et appliquer les permissions 750/640 quand possible.

Notez aussi le rôle du umask. Un umask trop permissif génère des fichiers world-writable malgré des chmod corrects. Sur VPS, contrôlez la configuration PHP-FPM et le user du pool.

Autres protections complémentaires quand chmod ne suffit pas

Les permissions sont une couche parmi d’autres. Pour durcir efficacement, combinez plusieurs mesures.

• Interdire l’édition de fichiers depuis le tableau de bord WordPress en définissant define('DISALLOW_FILE_EDIT', true)
• Déplacer le wp-config.php hors du répertoire web quand le serveur l’autorise
• Mettre en place une surveillance d’intégrité (hash des fichiers) pour détecter modifications non autorisées
• Utiliser SFTP avec clés plutôt que FTP et revoir les mots de passe FTP/DB régulièrement
• Configurer des règles .htaccess ou Nginx pour bloquer l’accès public à certains fichiers sensibles

Sur des environnements avancés, SELinux ou AppArmor peuvent imposer des contextes supplémentaires. Ne changez pas ces contextes sans compréhension, ils sont là pour renforcer la sécurité mais peuvent bloquer le fonctionnement si mal configurés.

Que faire si un malware a modifié vos permissions

Un comportement fréquent des infections est de mettre certaines sources en lecture seule (444) pour empêcher le nettoyage automatique. Si vous constatez cela, isolez le site : mettez un message d’entretien, changez tous les mots de passe, et ne supprimez rien à chaud sans analyse.

Étapes à suivre rapidement

• Exporter les logs et prendre une sauvegarde complète pour analyse forensique
• Scanner avec des outils d’analyse de malwares et comparer les fichiers core avec une copie propre
• Vérifier les tâches cron, les comptes FTP/SFTP et les clés SSH
• Restaurer depuis une sauvegarde saine si vous en avez une, sinon nettoyer fichier par fichier

Dans la pratique, la collaboration avec l’hébergeur est souvent nécessaire pour identifier l’origine de la compromission et rétablir les ownerships corrects au niveau système.

Erreurs courantes que j’ai souvent vues et comment les éviter

Voici des maladresses fréquentes et la manière de s’en prémunir

• Installer un plugin de backup qui crée des fichiers world-writable. Vérifiez les permissions des fichiers créés automatiquement.
• Exécuter des scripts avec sudo quand inutile. Résultat fréquent : owner changé et uploads cassés.
• Penser qu’un chmod 777 règle tout. Il masque un problème d’ownership et ouvre la porte à des scripts malveillants.
• Ne pas vérifier les restrictions imposées par un hébergeur géré. Certains environnements refusent toute modification

FAQ