# Permissions de fichiers WordPress : chmod, propriétaires et utilisateur PHP

> 644, 755, 440… derrière ces chiffres se cache une des causes les plus fréquentes de sites piratés ou de mises à jour impossibles.

- Auteur : Clément Hadrot
- Publié le : 2020-09-07
- Mis à jour le : 2020-09-07
- Catégorie : Sécurité
- URL : https://wpmoderne.dev.wordpress-developpement.fr/securite/permissions-fichiers-wordpress/

## L’essentiel

- Les répertoires en 755 et les fichiers en 644 forment la base saine
- wp-config.php gagne à passer en 440 quand le serveur le permet
- Un script de vérification repère les écarts en quelques secondes

Un client nous contacte régulièrement pour deux raisons opposées et pourtant liées à la même cause : soit son site a été piraté avec des fichiers modifiés en toute discrétion, soit il n'arrive plus à mettre à jour ses extensions parce que WordPress lui répond qu'il n'a pas les droits d'écriture nécessaires. Dans les deux cas, la réponse se trouve du côté des permissions de fichiers.

Sur un serveur Linux, chaque fichier et chaque dossier possède un propriétaire, un groupe et une série de droits de lecture, écriture et exécution. Bien réglés, ces droits limitent la casse en cas de faille ; mal réglés, ils l'aggravent ou bloquent le fonctionnement normal du site. Voici comment les régler correctement selon le mode d'exécution de PHP sur votre hébergement.

## Comprendre les trois acteurs : propriétaire, groupe, utilisateur PHP

Sur un serveur mutualisé classique, les fichiers WordPress appartiennent généralement à un compte utilisateur système correspondant à l'hébergement (par exemple `client1234`), et PHP s'exécute sous ce même compte grâce à un module comme **PHP-FPM** configuré en pool dédié, ou à une technologie de type **suPHP** / **suexec**. Dans ce cas de figure, PHP possède déjà les mêmes droits que le propriétaire des fichiers : il peut lire et écrire sans complication.

Sur d'autres configurations, plus anciennes ou plus génériques, PHP s'exécute sous l'utilisateur du serveur web lui-même (souvent `www-data` sur Debian/Ubuntu, ou `apache`), distinct du propriétaire réel des fichiers. C'est cette distinction qui détermine la marche à suivre.

## Les réglages de base recommandés

Le standard largement admis dans l'écosystème WordPress répartit les droits ainsi :

1. Tous les répertoires en **755** : le propriétaire peut lire, écrire et parcourir ; le groupe et les autres peuvent seulement lire et parcourir.
2. Tous les fichiers en **644** : le propriétaire peut lire et écrire ; le groupe et les autres peuvent seulement lire.
3. Le dossier `wp-content/uploads` reste en écriture pour PHP, puisque c'est là que sont déposés les médias, les caches et parfois les sauvegardes générées par des extensions.

Pour appliquer ces réglages en une passe depuis la racine du site :

```
find /chemin/vers/wordpress -type d -exec chmod 755 {} \;
find /chemin/vers/wordpress -type f -exec chmod 644 {} \;
```

> L'essentiel à retenir : Les répertoires en 755 et les fichiers en 644 forment la base saine ; wp-config.php gagne à passer en 440 quand le serveur le permet ; Un script de vérification repère les écarts en quelques secondes

## Le cas particulier de wp-config.php

Ce fichier contient les identifiants de connexion à la base de données : il mérite une protection renforcée. Quand le mode d'exécution de PHP le permet (typiquement en PHP-FPM avec pool dédié), le passer en **440** (lecture seule pour le propriétaire et le groupe, aucun droit pour les autres) empêche toute modification directe via le serveur web tout en laissant PHP le lire normalement.

```
chmod 440 wp-config.php
```

Attention : sur un hébergement où PHP s'exécute sous un utilisateur différent du propriétaire des fichiers, ce réglage strict peut au contraire empêcher WordPress de lire son propre fichier de configuration et provoquer une page blanche. Il convient donc de tester en environnement de préproduction avant d'appliquer ce changement en production, et de vérifier le mode d'exécution auprès de l'hébergeur en cas de doute.

## Un script de vérification rapide

Plutôt que de vérifier fichier par fichier, un script shell simple permet de repérer les écarts par rapport à la norme attendue :

```
find /chemin/vers/wordpress -type f ! -perm 644 -not -path "*/wp-content/uploads/*"
find /chemin/vers/wordpress -type d ! -perm 755
```

Toute ligne retournée mérite un examen : un fichier PHP passé en 777 par une extension mal codée, ou un dossier laissé en écriture pour tout le monde, sont des signaux qui reviennent souvent dans nos audits après incident.

## Les erreurs les plus fréquentes

- Passer l'ensemble du site en 777 « pour que ça marche » face à une erreur de permission, sans chercher la cause réelle du blocage.
- Oublier que les mises à jour automatiques de WordPress ont besoin d'un accès en écriture correctement configuré, faute de quoi elles échouent silencieusement.
- Changer les permissions sans vérifier au préalable sous quel utilisateur PHP s'exécute réellement sur l'hébergement.

> Face à une erreur de permission, la meilleure réaction n'est jamais d'ouvrir tous les droits : c'est de comprendre sous quel utilisateur PHP tourne réellement sur ce serveur précis.

## En résumé

Des permissions correctement réglées ne remplacent aucune des autres briques de sécurité d'un site WordPress, mais elles réduisent la surface d'attaque en cas de compromission d'une extension tierce, et elles évitent bien des allers-retours avec un support d'hébergement. Retenez le tandem 755 pour les dossiers, 644 pour les fichiers, avec un régime plus strict réservé à `wp-config.php` quand le mode d'exécution de PHP le permet.