Durcissement WordPress: permissions fichiers, wp-config et clés d’application

Tu veux un site WordPress rapide, propre et surtout difficile à compromettre ? Bonne nouvelle : un durcissement bien pensé ne demande pas forcément des heures de configuration. Dans ce guide, on va droit au but avec un hardening pragmatique et reproductible. On se concentre sur l’essentiel : permissions WordPress correctes, gestion du propriétaire des fichiers, durcissement de wp-config.php et rotation des salts, sans oublier la désactivation de l’éditeur de fichiers dans l’admin. Tu vas manipuler CHMOD 644 755, vérifier le propriétaire et le groupe, activer DISALLOW_FILE_EDIT, et blinder la base avec quelques commandes SSH simples. Ces mots-clés ne sont pas là pour le style : ils sont au cœur d’un durcissement WordPress (“hardening”) efficace.

Pourquoi s’attarder sur ces points ? Parce que 80 % des piratages exploitent des failles banales : fichiers en écriture globale, wp-config exposé, clés obsolètes, plugins modifiés via l’éditeur, etc. En appliquant ces règles, tu fais chuter la surface d’attaque, tu simplifies les mises à jour, et tu rends toute compromission bien plus coûteuse pour l’attaquant. Ce guide, c’est un pas-à-pas actionnable : lis, exécute, vérifie, et dors plus sereinement ce soir.

Durcissement WordPress: l’essentiel à comprendre avant d’agir

Le durcissement (“hardening”) consiste à réduire la surface d’attaque en limitant les privilèges, en cloisonnant les accès et en imposant des contrôles stricts. Sur WordPress, l’essentiel se joue au niveau du système de fichiers et des constantes de configuration. Quand les permissions sont justes et que wp-config.php est blindé, beaucoup d’exploits deviennent inopérants ou bien moins efficaces.

• Moins de droits = moins d’impact en cas d’exploitation.
• Un propriétaire et un groupe cohérents = moins de contournements d’écriture.
• Un wp-config.php restreint = secrets et accès protégés.
• Des salts solides et renouvelés = sessions invalidées et cookies inutilisables après rotation.
• L’éditeur de fichiers désactivé = pas de backdoor ajoutée via le tableau de bord.

Si tu veux creuser les fondamentaux, la doc officielle est une excellente base : Hardening WordPress et File Permissions. Ici, on passe en mode pratique.

Configurer les permissions WordPress: CHMOD 644 pour les fichiers, 755 pour les dossiers

Le couple standard le plus sûr et compatible dans la majorité des hébergements est :

• Fichiers: 644 (lecture/écriture pour le propriétaire, lecture pour le groupe et les autres).
• Dossiers: 755 (lecture/exécution pour tous, écriture pour le propriétaire uniquement).

Évite absolument 777 (écriture globale). C’est comme laisser les clés sur la porte. Pour appliquer en masse depuis la racine du site (par ex. /var/www/html), exécute en SSH :

# Depuis la racine WordPressfind . -type f -exec chmod 644 {} \;find . -type d -exec chmod 755 {} \;

Pour quelques fichiers sensibles, durcis davantage :

• wp-config.php : 600 ou 640 selon ton environnement (si le groupe du serveur web doit lire).
• .htaccess (Apache) : 644.
• Clés SSH, fichiers de déploiement, etc. : 600.

Si tes mises à jour WordPress échouent après ce durcissement, c’est rarement la faute des permissions en elles-mêmes. Le coupable, c’est souvent le propriétaire des fichiers ou le groupe. On règle ça ensuite.

Pourquoi “CHMOD 644 755” est un bon point d’équilibre

Le serveur web (Apache, Nginx via PHP-FPM) n’a pas besoin d’écrire partout. Il doit pouvoir lire les fichiers PHP et servir les ressources. L’écriture est requise principalement dans wp-content (uploads, cache) et parfois pendant des mises à jour. En pratique, si l’ownership est correct, 644/755 suffit à WordPress pour fonctionner et se mettre à jour en direct.

Définir un propriétaire et un groupe cohérents (chown, chgrp)

Les permissions seules ne suffisent pas. Le propriétaire et le groupe déterminent qui a réellement le droit d’écrire. Sur Ubuntu/Debian, l’utilisateur du serveur web est souvent www-data. Deux schémas efficaces :

• Schéma simple (environnement mutualisé) : propriétaire = utilisateur FTP/SFTP, groupe = www-data. Le serveur lit tout, mais n’écrit que là où c’est nécessaire.
• Schéma déploiement (serveur dédié) : propriétaire = utilisateur de déploiement (ex. deploy), groupe = www-data. On place setgid sur wp-content pour l’héritage de groupe.

Commandes utiles (à adapter à ton chemin et utilisateur) :

# Depuis la racine WordPresssudo chown -R deploy:www-data .find . -type d -exec chmod 755 {} \;find . -type f -exec chmod 644 {} \;# Donner au serveur web l'écriture uniquement là où c'est utilesudo chown -R deploy:www-data wp-contentsudo chmod g+w -R wp-content# Optionnel: setgid sur les dossiers de cache/uploads pour hériter du groupefind wp-content -type d -exec chmod 2755 {} \;

Sur certains hébergeurs, WordPress bascule automatiquement sur la méthode FTP si l’ownership n’est pas idéal. Ce n’est pas bloquant, mais la méthode direct est plus simple à maintenir si la sécurité le permet. On en reparle côté wp-config.php.

Durcir wp-config.php: accès minimal, secrets protégés, fonctionnalités restreintes

Le fichier wp-config.php concentre tes identifiants de base de données, tes clés d’application et des constantes critiques. C’est la première chose qu’un attaquant essaiera de lire. Durcissons-le.

1) Restreindre les permissions de wp-config.php

Applique 600 (ou 640 si le groupe serveur doit lire) :

chmod 600 wp-config.php

Tu peux aussi déplacer wp-config.php un niveau au-dessus de la racine web si ton hébergement le permet. WordPress le détecte automatiquement.

2) Bloquer l’accès HTTP direct (Apache/Nginx)

Sur Apache, ajoute dans .htaccess à la racine :

<Files wp-config.php>  order allow,deny  deny from all</Files>

Sur Nginx, dans le server {} :

location ~* wp-config.php {  deny all;}

3) Désactiver l’éditeur de fichiers (et éventuellement les modifs)

L’éditeur intégré permet de modifier des plugins/thèmes depuis l’admin. Pratique, mais dangereux. Ajoute dans wp-config.php :

define('DISALLOW_FILE_EDIT', true);

Pour interdire aussi l’installation/mise à jour de thèmes et plugins via l’admin (à activer seulement si tes déploiements sont gérés autrement) :

define('DISALLOW_FILE_MODS', true);

Cette combinaison limite l’impact d’une session admin compromise.

4) Forcer l’admin en HTTPS et clarifier l’environnement

Si ton site a un certificat TLS, active :

define('FORCE_SSL_ADMIN', true);

Et précise l’environnement pour éviter des comportements risqués en prod :

define('WP_ENVIRONMENT_TYPE', 'production');

5) Maîtriser la méthode d’écriture des fichiers

Si l’ownership est correct et que le serveur doit pouvoir écrire (ex. mise à jour auto mineure), autorise la méthode directe :

define('FS_METHOD', 'direct');

Sur un mutualisé, tu peux rester en FTP/SFTP si nécessaire. L’objectif reste le même : garder le périmètre d’écriture le plus réduit possible.

Clés d’application et salts: renforce l’authentification et invalide les sessions

Les Authentication Keys et Salts signent tes cookies de session. Si elles sont faibles, prévisibles ou compromises, un attaquant peut réutiliser des cookies volés. Il faut des valeurs aléatoires de forte entropie et une rotation périodique.

1) Générer des clés et salts solides

Utilise le service officiel pour obtenir des valeurs fortes, puis colle-les dans wp-config.php :

// Exemple: remplacer par les valeurs généréesdefine('AUTH_KEY',         '...');define('SECURE_AUTH_KEY',  '...');define('LOGGED_IN_KEY',    '...');define('NONCE_KEY',        '...');define('AUTH_SALT',        '...');define('SECURE_AUTH_SALT', '...');define('LOGGED_IN_SALT',   '...');define('NONCE_SALT',       '...');

Après remplacement, toutes les sessions actives seront invalidées. C’est voulu.

2) Automatiser la rotation avec WP-CLI

Si tu as WP-CLI, tu peux mélanger/rafraîchir les salts :

# À la racine du sitewp config shuffle-salts

Astuce : ajoute une tâche CRON trimestrielle pour renouveler silencieusement :

0 3 1 */3 * cd /var/www/html && wp config shuffle-salts --allow-root

Réserve cette automatisation aux sites où l’impact d’une déconnexion périodique est acceptable.

Empêcher l’exécution de PHP dans uploads et désactiver l’indexation de répertoires

Les webshells se cachent souvent dans wp-content/uploads. Interdis l’exécution de PHP dans ce dossier.

Apache (.htaccess dans uploads)

<FilesMatch "\.(php|php\d*)$">  Order allow,deny  Deny from all</FilesMatch>Options -Indexes

Nginx (config serveur)

location ~* /wp-content/uploads/.*\.(php|php\d*)$ {  deny all;}autoindex off;

Bonus : si tu utilises un plugin de cache, vérifie que ses répertoires d’écriture ont le strict minimum de droits (généralement 775 au plus si tu relies des groupes).

Procédure express: durcir un WordPress en 30 à 45 minutes

1. Audit express: note l’utilisateur serveur (www-data ?), le chemin de la racine, et la méthode actuelle de mises à jour (direct/FTP).
2. Ownership: applique chown -R deploy:www-data (ou ton couple équivalent).
3. Permissions: fichiers en 644, dossiers en 755. wp-config.php en 600.
4. wp-config.php: DISALLOW_FILE_EDIT, éventuellement DISALLOW_FILE_MODS, FORCE_SSL_ADMIN, WP_ENVIRONMENT_TYPE, et FS_METHOD si nécessaire.
5. Salts: régénère depuis le service officiel ou via wp config shuffle-salts.
6. Uploads: bloque l’exécution PHP et l’indexation.
7. Vérifications: mises à jour, envoi média, front OK, logs error.log propres.

Cette routine suffit à éliminer les faiblesses les plus courantes, tout en restant compatible avec la majorité des hébergements.

Besoin d’un renfort sécurité en urgence ?

Nos experts durcissent ton WordPress (permissions, wp-config, clés) et réparent les dégâts si besoin, en moins de 2 heures.

Durcir et sécuriser mon site

Validation et tests après durcissement

Après toute modification, valide le fonctionnement de bout en bout :

• Mises à jour : lance une mise à jour mineure d’un plugin pour vérifier la méthode d’écriture.
• Envoi de média : teste un upload et la génération de vignettes.
• Cache : purge, régénère, contrôle les droits du répertoire.
• Logs : surveille /var/log/nginx/error.log ou /var/log/apache2/error.log pour déceler des 403 inattendus.
• Intégrité : compare les empreintes des fichiers cœur via wp core verify-checksums.

Si quelque chose coince, reviens en arrière étape par étape. L’erreur la plus courante : un propriétaire/groupe incohérent plutôt qu’un problème de chmod.

Bonnes pratiques complémentaires pour un WordPress blindé

Limiter les points d’entrée

• XML-RPC : si tu ne l’utilises pas (app mobile, Jetpack), limite ou désactive.
• WP-Admin : restreins par IP si tu as une IP fixe ou via un VPN.
• WAF : un pare-feu applicatif (ex. niveau CDN) filtre beaucoup d’attaques triviales.

Surveiller et alerter

• Active les alertes de connexion admin, de fichiers modifiés et de tentatives suspectes.
• Vérifie régulièrement la taille et le contenu d’wp-content/uploads.

Garder la main sur la maintenance

• Mises à jour régulières cœur/extensions/thèmes après test.
• Sauvegardes hors serveur + restauration testée.
• Scan de vulnérabilités et revue mensuelle de wp-config.php et des salts.

Chez WP Builders, on applique ces contrôles dans nos contrats de maintenance, avec monitoring et interventions rapides quand un signal passe au rouge. Tu restes propriétaire des décisions, on s’occupe du côté technique et répétitif.

Cas particuliers et pièges à éviter

• Hébergement mutualisé : certains forcent des permissions plus laxistes. Teste d’abord en préprod, puis durcis progressivement.
• Multisite : attention aux répertoires de médias et aux règles de réécriture spécifiques. Le principe 644/755 reste valide.
• Plugins de cache/optimisation : lis leur doc sur les droits nécessaires (certains réclament 775 sur une poignée de dossiers).
• Livraisons CI/CD : s’assure que le pipeline réapplique chown/chmod après déploiement.

Checklist finale “hardening minimal viable”

• Fichiers 644, dossiers 755 ; wp-config.php 600/640.
• DISALLOW_FILE_EDIT activé (et DISALLOW_FILE_MODS si ton process de déploiement le permet).
• Clés et salts robustes, rotation planifiée (WP-CLI conseillé).
• Exécution PHP bloquée dans uploads ; indexation dossiers désactivée.
• FORCE_SSL_ADMIN et environnement production définis.
• Ownership cohérent : propriétaire et groupe clairs, écriture limitée.

En appliquant cette checklist, tu réduis drastiquement les risques les plus communs, sans transformer ton quotidien en casse-tête. Et si tu veux aller plus loin (audit, durcissement serveur, CI/CD sécurisé), on peut t’accompagner.