2026年11月12日
2026年11月12日
Permissions recommandées pour WordPress : 755, 644 et wp-config.php
Cet article est une édition localisée de l'original japonais. Lire l'original en japonais
Pour les permissions de fichiers de WordPress, la base est 755 pour les répertoires et 644 pour les fichiers. Pour wp-config.php, qui contient les informations de connexion à la base de données, on restreint encore davantage le nombre de personnes pouvant le lire. Ne vous arrêtez pas aux chiffres : vérifiez aussi qui est propriétaire des fichiers et sous quel utilisateur PHP s'exécute, ce qui permet d'éviter à la fois les fuites d'informations et le problème des « mises à jour impossibles ». Les valeurs recommandées dans cet article ont été vérifiées en novembre 2026 dans le guide officiel de WordPress « Hardening WordPress » (renforcer la sécurité de WordPress).
Lire les chiffres des permissions
Les permissions se composent de trois groupes, « propriétaire, groupe, autres », et s'expriment par la somme de la lecture (4), de l'écriture (2) et de l'exécution (1).
| Valeur | Notation | Signification |
|---|---|---|
| 755 | rwxr-xr-x | Le propriétaire peut lire, écrire et entrer dans le répertoire ; les autres peuvent seulement lire et entrer (pour les répertoires) |
| 644 | rw-r--r-- | Le propriétaire peut lire et écrire ; les autres peuvent seulement lire (pour les fichiers) |
| 640 | rw-r----- | Le propriétaire peut lire et écrire, le groupe peut lire, les autres ne peuvent rien faire |
| 600 | rw------- | Seul le propriétaire peut lire et écrire |
| 440 / 400 | r--r----- / r-------- | Personne ne peut écrire ; seuls le propriétaire (et le groupe) peuvent lire |
L'« exécution (x) » d'un répertoire est le droit d'entrer dans ce répertoire. Si vous retirez x d'un répertoire, les fichiers qu'il contient ne peuvent plus être lus.
Valeurs recommandées pour WordPress
| Cible | Valeur recommandée | Remarque |
|---|---|---|
| Répertoires | 755 (750 si, sur un serveur mutualisé, vous ne voulez pas les exposer aux autres) | Même les mises à jour automatiques officielles ramènent les répertoires à 755 |
| Fichiers | 644 (640 dans le même cas) | Même les mises à jour automatiques officielles ramènent les fichiers à 644 |
| wp-config.php | Restreindre la lecture à vous-même et au serveur web | L'explication officielle parle de « 400 ou 440 en général ». Dans un environnement où PHP s'exécute sous le même utilisateur que le propriétaire du fichier, 600 ou 400 fonctionnent aussi |
| .htaccess | 644 | Si vous laissez WordPress le réécrire en enregistrant les réglages des permaliens, l'utilisateur d'exécution de PHP doit pouvoir y écrire |
| wp-content/uploads | Répertoires 755, fichiers 644 | Donnez-en la propriété à un utilisateur dans lequel PHP peut écrire |
Il n'est pas nécessaire de passer en 777 (accessible en écriture à tous). Sur un serveur mutualisé, d'autres utilisateurs du même serveur risqueraient de modifier vos fichiers.
Certains hébergeurs définissent leurs propres valeurs recommandées (la façon d'exécuter PHP varie selon les serveurs). Si le manuel de votre serveur indique des valeurs, suivez-les en priorité.
Comment penser le propriétaire
Selon l'explication officielle, les fichiers appartiennent à votre propre compte utilisateur et vous devez pouvoir y écrire. Seuls les fichiers dans lesquels WordPress doit écrire (uploads, les thèmes si vous utilisez l'éditeur de thème, etc.) doivent avoir un propriétaire ou un groupe tel que l'utilisateur d'exécution du serveur web (PHP) puisse y écrire.
Si vous mettez l'ensemble sous la propriété de l'utilisateur du serveur web, par exemple avec chown -R www-data:www-data, PHP peut réécrire tous les fichiers. En cas d'exploitation d'une faille d'extension, les dégâts risquent de s'étendre ; vérifiez donc d'abord l'état actuel avant de décider.
Lorsque les mises à jour d'extensions ou du cœur demandent des « informations de connexion (nom d'hôte, identifiant et mot de passe FTP) », la cause est le plus souvent cette différence de propriétaire. WordPress ne choisit la méthode d'écriture directe des fichiers que lorsque le propriétaire des fichiers créés par PHP est le même que celui des fichiers de WordPress. Sinon, il demande une mise à jour via FTP. Ne passez pas les permissions en 777 : corrigez en alignant le propriétaire.
Vérifier la configuration actuelle
Connectez-vous en SSH au répertoire de WordPress et vérifiez les valeurs et le propriétaire avec les commandes suivantes. Adaptez les chemins à votre environnement.
cd /var/www/html
# Permissions, propriétaire et groupe de wp-config.php
stat -c '%a %U:%G %n' wp-config.php
# Rechercher les fichiers et répertoires modifiables par les autres utilisateurs
find . -perm -o=w ! -type l
# Rechercher les fichiers PHP dans uploads (il ne devrait normalement y en avoir aucun)
find wp-content/uploads -type f -name '*.php'
L'utilisateur sous lequel PHP s'exécute lors d'un accès web se vérifie dans la configuration du serveur (par exemple user dans le pool PHP-FPM) ou dans le manuel de l'hébergeur. Il n'est pas nécessairement identique à l'utilisateur avec lequel vous vous connectez en SSH.
Si vous trouvez dans uploads un fichier PHP inconnu, soupçonnez une altération et, avant de le supprimer, notez la date et le contenu du fichier.
Corriger les permissions en une fois
Exécutez ces commandes dans le répertoire de WordPress. Faites une sauvegarde avant de les lancer.
cd /var/www/html
# Mettre les répertoires en 755 et les fichiers en 644
find . -type d -exec chmod 755 {} +
find . -type f -exec chmod 644 {} +
# Restreindre wp-config.php (exemple d'un environnement où PHP s'exécute sous le propriétaire du fichier)
chmod 600 wp-config.php
Pour wp-config.php, choisissez la valeur selon votre environnement, comme suit.
- PHP s'exécute sous le même utilisateur que le propriétaire du fichier (de nombreux hébergements mutualisés, PHP-FPM par utilisateur) : 600 ou 400
- Le propriétaire est votre compte et le serveur web lit le fichier en tant que groupe : 640 ou 440, et le groupe est celui du serveur web
# Exemple : propriétaire = vous, groupe = serveur web (www-data), avec 640
sudo chgrp www-data wp-config.php
chmod 640 wp-config.php
Après le réglage, ouvrez le site et l'administration et vérifiez que l'affichage et la connexion fonctionnent. Si vous obtenez un écran blanc ou une erreur, PHP ne peut pas lire wp-config.php. Remettez la valeur à 644, puis revoyez le propriétaire et le groupe.
Avec 400 ou 440, les extensions qui écrivent dans wp-config.php (par exemple celles qui y inscrivent des réglages de cache) échouent. Autorisez temporairement l'écriture uniquement pendant la configuration de ces extensions.
Empêcher la lecture de wp-config.php depuis le web
Si PHP fonctionne normalement, accéder à wp-config.php dans le navigateur n'affiche pas son contenu. Pour éviter que le code source s'affiche si PHP s'arrête, refusez aussi l'accès côté serveur web. Avec Apache 2.4, écrivez ce qui suit dans le .htaccess du répertoire où se trouve WordPress (les anciennes directives Order Deny,Allow / Deny from all sont la syntaxe d'Apache 2.2).
<Files "wp-config.php">
Require all denied
</Files>
La procédure détaillée est expliquée dans « Refuser l'accès à wp-config.php ».
Quant à .htaccess lui-même, son accès est déjà refusé par la configuration standard d'Apache (<Files ".ht*"> de httpd.conf).
Selon l'explication officielle, vous pouvez aussi déplacer wp-config.php un répertoire au-dessus de celui de WordPress. WordPress cherche dans le répertoire parent s'il n'y a pas de wp-config.php dans le même répertoire. Toutefois, le guide officiel mentionne lui-même l'avis selon lequel l'effet est faible, ainsi que le fait que cela peut devenir dangereux si c'est mal fait. Si vous le déplacez, vérifiez que le répertoire parent n'est pas un répertoire public.
Empêcher l’exécution de PHP dans uploads
uploads est un répertoire dans lequel WordPress écrit : c'est donc un endroit où les attaques déposent facilement des fichiers. Si PHP n'y est pas exécuté, un fichier déposé ne fonctionnera pas.
Avec Apache 2.4, créez wp-content/uploads/.htaccess et écrivez ce qui suit.
<FilesMatch "\.(php|phtml|phar)$">
Require all denied
</FilesMatch>
Pour utiliser Require dans .htaccess, il faut que AllowOverride l'autorise côté serveur. Sinon, vous obtenez une erreur 500 ou le réglage est ignoré. Après l'écriture, ouvrez l'URL d'un fichier PHP inexistant, comme https://example.com/wp-content/uploads/test.php, et vérifiez que vous obtenez un 403 (si vous obtenez toujours un 404, le réglage n'est pas pris en compte).
Avec Nginx, placez ce qui suit dans le bloc server, avant la location ~ \.php$ qui traite PHP. Les location par expression régulière sont comparées de haut en bas, et la première qui correspond est utilisée.
location ~* ^/wp-content/uploads/.*\.(php|phtml|phar)$ {
deny all;
}
Après la modification, vérifiez la syntaxe avec nginx -t, puis rechargez.
Par ailleurs, le téléversement de médias de WordPress n'accepte pas par défaut les fichiers autres que les types autorisés (images, PDF, etc.). Depuis l'administration, il n'est normalement pas possible de téléverser un fichier PHP comme média.
Points d’attention
- Avant de modifier les permissions, faites une sauvegarde des fichiers et de la base de données.
- Si vous changez les permissions avec un logiciel FTP, certains serveurs ne prennent pas en charge la modification en masse. Quand les fichiers sont nombreux,
finden SSH est plus rapide et évite les oublis. - Si des informations de connexion FTP vous sont demandées lors d'une mise à jour, n'élargissez pas les permissions : vérifiez le propriétaire. Consultez aussi « Corriger les erreurs de permissions de WordPress ».
- Exécutez régulièrement les commandes de vérification ci-dessus (fichiers modifiables par les autres utilisateurs, PHP dans uploads) : vous repérerez plus vite un réglage dégradé ou une altération.
Une question sur WordPress ? L'éditeur de ce site est basé au Japon et répond en japonais. Contact (en japonais)