Permissions des Fichiers et Dossiers WordPress : Guide Complet 2026

Pourquoi vos permissions de fichiers WordPress vous exposent à un risque majeur

Selon le rapport Hacked Website Report de Sucuri (2024), les mauvaises configurations serveur — dont les permissions de fichiers incorrectes — sont impliquées dans plus de 36 % des compromissions WordPress. Pourtant, c’est l’un des aspects les plus négligés lors de l’installation ou de la migration d’un site.

Imaginez laisser la porte de votre commerce grande ouverte la nuit : des permissions trop permissives font exactement ça. Un fichier wp-config.php lisible par tous, un dossier uploads/ qui permet l’exécution de PHP, ou un répertoire wp-includes/ modifiable par le serveur web — ce sont autant de vecteurs d’attaque exploités quotidiennement par des bots automatisés.

Dans ce guide complet, vous allez apprendre exactement quelles permissions appliquer, comment les vérifier et comment les corriger — que vous ayez accès via SSH, FTP, WP-CLI ou votre panneau d’hébergement.

Comprendre le système de permissions Linux (chmod)

WordPress s’exécute sur des serveurs Linux, qui utilisent un système de permissions à 3 niveaux :

• Propriétaire (owner) : l’utilisateur système qui possède le fichier (souvent votre compte FTP ou SSH)
• Groupe (group) : le groupe auquel appartient le serveur web (souvent www-data sur Ubuntu/Debian, apache sur CentOS)
• Autres (others) : tous les autres utilisateurs du système

Chaque niveau dispose de 3 types de droits :

• Lecture (r = 4) : voir le contenu du fichier ou lister un dossier
• Écriture (w = 2) : modifier, créer ou supprimer
• Exécution (x = 1) : exécuter le fichier ou accéder à un dossier

Ces valeurs s’additionnent : 755 signifie propriétaire (rwx = 7) + groupe (r-x = 5) + autres (r-x = 5). C’est la permission standard recommandée pour les dossiers WordPress.

Les permissions recommandées pour WordPress en 2026

Voici les paramètres officiellement recommandés par l’équipe WordPress.org, adaptés aux bonnes pratiques de sécurité 2026 :

Permissions pour les dossiers

Permissions pour les fichiers

⚠️ Règle d’or : N’utilisez jamais la permission 777 (lecture + écriture + exécution pour tout le monde). C’est l’équivalent de laisser votre clé sous le paillasson pour n’importe quel passant — y compris les bots malveillants.

Comment vérifier et corriger les permissions WordPress

Via SSH (méthode recommandée)

Si vous avez accès SSH à votre serveur, voici les commandes pour appliquer les bonnes permissions depuis la racine WordPress :

# Aller dans le dossier WordPress
cd /var/www/html/votre-site

# Corriger les dossiers (755)
find . -type d -exec chmod 755 {} \;

# Corriger les fichiers (644)
find . -type f -exec chmod 644 {} \;

# Sécuriser wp-config.php en priorité
chmod 640 wp-config.php

# Détecter les fichiers dangereux avec 777
find . -type f -perm 777
find . -type d -perm 777

Ces commandes couvrent l’ensemble de l’installation WordPress en quelques secondes. Exécutez-les après chaque migration ou restauration de backup.

Via WP-CLI

WP-CLI permet de vérifier l’intégrité des fichiers core WordPress :

# Vérifier l'intégrité des fichiers core
wp core verify-checksums

# Diagnostic de sécurité général
wp doctor check --all

Via cPanel / Plesk

Sans accès SSH, la plupart des hébergeurs proposent un gestionnaire de fichiers :

1. Connectez-vous à cPanel → Gestionnaire de fichiers
2. Naviguez jusqu’au dossier racine de WordPress
3. Faites un clic droit → Modifier les permissions
4. Saisissez la valeur numérique (644 pour les fichiers, 755 pour les dossiers)
5. Cochez « Appliquer récursivement aux sous-dossiers »

Via FTP/SFTP avec FileZilla

Dans FileZilla, faites un clic droit sur un fichier ou dossier → « Permissions du fichier ». Saisissez la valeur numérique et cochez « Inclure les sous-dossiers ». Préférez toujours SFTP (port 22) plutôt que FTP non chiffré.

Cas critiques : les fichiers à sécuriser absolument

wp-config.php : la cible prioritaire des attaquants

Ce fichier contient vos identifiants de base de données, vos clés de sécurité et le préfixe de vos tables. Sa compromission expose l’intégralité de votre site. En plus de chmod 640, envisagez de le déplacer un niveau au-dessus de la racine web (WordPress le détectera automatiquement). Pour aller plus loin, notre guide sécuriser wp-config.php : toutes les techniques détaille toutes les protections disponibles.

Le dossier wp-content/uploads/ : bloquer l’exécution PHP

Ce dossier doit pouvoir être écrit par le serveur pour les médias, mais ne doit jamais exécuter de fichiers PHP. Créez un fichier .htaccess dans wp-content/uploads/ avec ce contenu :

# Bloquer l'exécution PHP dans le dossier uploads
<Files "*.php">
  deny from all
</Files>

Cette protection est souvent oubliée et est régulièrement exploitée via des attaques d’upload de webshells. Pour approfondir la configuration d’Apache, consultez notre guide sécuriser le fichier .htaccess WordPress.

wp-admin/ et wp-includes/ : intouchables

Ces deux répertoires contiennent le cœur de WordPress. S’ils peuvent être modifiés par le serveur web, un attaquant ayant exploité une faille peut altérer le core ou installer une backdoor persistante. Permission stricte : 755, propriétaire = votre compte utilisateur (jamais www-data).

Propriété des fichiers (ownership) : owner vs www-data

Au-delà du chmod, la propriété des fichiers est tout aussi critique. Sur un serveur Linux :

• Le propriétaire doit être votre compte utilisateur (ex: monsite), jamais www-data
• Le groupe peut être www-data pour permettre la lecture par le serveur web
• Si www-data est propriétaire, le processus web peut modifier vos fichiers — risque majeur en cas de compromission

# Corriger la propriété (remplacez "monsite" par votre utilisateur)
chown -R monsite:www-data /var/www/html/votre-site/

# Vérifier la propriété actuelle
ls -la /var/www/html/votre-site/

Sur les hébergements mutualisés utilisant suPHP ou PHP-FPM avec des pools dédiés, le comportement peut différer — le propriétaire et l’utilisateur PHP sont souvent identiques, ce qui simplifie la gestion.

Surveiller les modifications de fichiers avec des plugins

La surveillance en temps réel est indispensable pour détecter toute modification suspecte des permissions ou du contenu des fichiers :

• Wordfence Security : scanner de fichiers avec comparaison contre les checksums officiels WordPress
• iThemes Security (SolidSecurity) : tableau de bord des permissions et alertes par email
• WP Cerber Security : monitoring des fichiers en temps réel avec journal d’activité

Ces outils s’intègrent parfaitement dans une démarche d’audit de sécurité WordPress complet et permettent de détecter rapidement un fichier modifié après une intrusion.

FAQ — Permissions des fichiers WordPress

Quelles permissions pour WordPress sur un hébergement mutualisé ?

Sur les hébergements mutualisés (OVH, o2switch, Ionos), PHP tourne souvent en mode suPHP ou PHP-FPM avec un utilisateur dédié par site. Dans ce cas, 755 pour les dossiers et 644 pour les fichiers restent la règle standard. Pour wp-config.php, 600 suffit puisque PHP et le propriétaire sont le même utilisateur.

Pourquoi ma mise à jour WordPress échoue-t-elle après avoir changé les permissions ?

WordPress doit pouvoir écrire dans certains dossiers pour les mises à jour automatiques : principalement wp-content/ et la racine. Si le groupe propriétaire (www-data) n’a pas les droits d’écriture, les mises à jour échouent. Vérifiez que wp-content/ est bien en 755 avec le groupe www-data, ou activez les mises à jour via SFTP en configurant FS_METHOD dans wp-config.php.

Comment détecter si mes fichiers ont été modifiés par un attaquant ?

Utilisez wp core verify-checksums via WP-CLI, ou un plugin comme Wordfence. Comparez les dates de modification des fichiers PHP avec votre dernière mise à jour connue. Un fichier modifié récemment sans votre intervention est un signal d’alerte critique. Référez-vous à notre checklist sécurité WordPress 2026 pour une procédure de vérification complète.

Les permissions 777 sont-elles vraiment si dangereuses ?

Absolument. Sur un hébergement mutualisé, chmod 777 permet à n’importe quel utilisateur du serveur — y compris d’autres sites hébergés sur la même machine — de modifier vos fichiers. Sur un VPS, tout processus compromis peut altérer votre installation. Selon Patchstack, de nombreux incidents impliquent des fichiers avec des permissions trop ouvertes comme vecteur de persistance post-infection.

Conclusion : Les permissions, fondation de votre sécurité WordPress

Les permissions de fichiers sont la première ligne de défense de votre WordPress — avant même les plugins de sécurité ou les pare-feux. Une configuration correcte réduit drastiquement la surface d’attaque et limite considérablement les dégâts en cas de compromission partielle.

Récapitulatif rapide :

• ✅ Dossiers : 755
• ✅ Fichiers PHP : 644
• ✅ wp-config.php : 640 ou 600
• ✅ Jamais 777 nulle part
• ✅ Bloquer l’exécution PHP dans uploads/
• ✅ Propriétaire = votre compte, jamais www-data

Appliquer ces recommandations prend moins de 5 minutes via SSH — et peut vous éviter des semaines de nettoyage post-hack. Vous souhaitez un audit complet de votre installation ? Contactez notre équipe d’experts WordPress ou découvrez nos services de sécurité WordPress.