Sécuriser wp-config.php dans WordPress

Le fichier wp-config.php à la racine de toute installation WordPress contient les identifiants de la base de données (hôte, nom, utilisateur, mot de passe), les clés de sécurité et les salts secrets ainsi que des constantes de configuration centrales. Si ce fichier tombe entre de mauvaises mains, c'est pratiquement tout le site qui est compromis. C'est donc le fichier unique le plus important à sécuriser. Ce guide présente quatre mesures de renforcement : générer des clés de sécurité fraîches, définir des permissions de fichier restrictives, bloquer l'accès HTTP direct au fichier et ajouter des constantes protectrices comme DISALLOW_FILE_EDIT. En option, le fichier peut être déplacé un niveau au-dessus du webroot. Toutes les étapes se réalisent en une vingtaine de minutes via SFTP/SSH et la configuration .htaccess ou nginx.

Étape 1 : Régénérer les clés de sécurité et les salts

WordPress utilise huit chaînes secrètes (AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY et les quatre valeurs _SALT correspondantes) pour chiffrer les cookies de connexion et les nonces. Si ces valeurs ont déjà été publiques (par exemple dans une sauvegarde accessible sur le web) ou n'ont jamais été changées, vous devriez les régénérer. WordPress fournit un générateur officiel pour cela :

# Fetch current random values:
https://api.wordpress.org/secret-key/1.1/salt/

Dans wp-config.php, remplacez le bloc existant par les valeurs fraîchement générées :

define( 'AUTH_KEY',         'hier-langer-zufallswert' );
define( 'SECURE_AUTH_KEY',  'hier-langer-zufallswert' );
define( 'LOGGED_IN_KEY',    'hier-langer-zufallswert' );
define( 'NONCE_KEY',        'hier-langer-zufallswert' );
define( 'AUTH_SALT',        'hier-langer-zufallswert' );
define( 'SECURE_AUTH_SALT', 'hier-langer-zufallswert' );
define( 'LOGGED_IN_SALT',   'hier-langer-zufallswert' );
define( 'NONCE_SALT',       'hier-langer-zufallswert' );

Après enregistrement, tous les utilisateurs connectés sont déconnectés – c'est voulu et un moyen efficace d'invalider les sessions volées.

Étape 2 : Définir les permissions de fichier

wp-config.php doit être lisible par le serveur web mais inaccessible aux autres utilisateurs. La recommandation est 600 (seul le propriétaire peut lire/écrire) ou 640 si le groupe du serveur web a besoin d'un accès en lecture :

# Only owner reads and writes
chmod 600 wp-config.php

# Alternatively, if the web server group must read
chmod 640 wp-config.php

Ne mettez jamais 777 ou 666 – cela permet à n'importe quel utilisateur du système de lire le fichier et d'extraire les identifiants de la base de données.

Étape 3 : Bloquer l'accès HTTP direct

Normalement wp-config.php est exécuté comme PHP et ne produit aucune sortie. Toutefois, si le traitement PHP échoue (mauvaise configuration, migration de serveur), le contenu en clair pourrait être servi. Bloquez l'accès direct en plus au niveau du serveur web.

Apache (.htaccess)

<Files wp-config.php>
    Require all denied
</Files>

nginx

location = /wp-config.php {
    deny all;
    return 403;
}

Étape 4 : Ajouter des constantes de renforcement

Dans wp-config.php, au-dessus de la ligne /* That's all, stop editing! */, ajoutez les constantes suivantes :

// Disable the file editor in the admin area (prevents editing
// theme and plugin code via wp-admin)
define( 'DISALLOW_FILE_EDIT', true );

// Optional: completely prevent installing/updating plugins and
// themes via the dashboard (strictest variant)
// define( 'DISALLOW_FILE_MODS', true );

// Disable debug output in production
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );

// Enforce encrypted connections in the admin area only
define( 'FORCE_SSL_ADMIN', true );

// Limit automatic core updates to security releases
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

DISALLOW_FILE_EDIT est particulièrement important : sans cette constante, un attaquant qui prend le contrôle d'un compte administrateur peut exécuter du code PHP arbitraire directement via Apparence » Éditeur de thème.

Optionnel : Déplacer wp-config.php hors du webroot

WordPress cherche aussi wp-config.php un niveau de répertoire au-dessus du webroot. Si votre WordPress se trouve sous /var/www/html/, vous pouvez déplacer le fichier vers /var/www/wp-config.php. Il se trouve alors hors de la zone accessible par HTTP.

Attention : Cela ne fonctionne de manière fiable que sur les installations classiques mono site avec un webroot dédié. Sur l'hébergement mutualisé, où plusieurs sites partagent le même niveau parent, le déplacer peut provoquer des conflits. En cas de doute, vérifiez avec votre hébergeur.

Comment vérifier que le renforcement fonctionne ?

1. Ouvrez https://votre-domaine.com/wp-config.php dans le navigateur. Attendu : une page vide (exécution PHP) ou 403 Forbidden (accès bloqué) – jamais de code source PHP lisible.
2. Via le terminal :

   curl -s -o /dev/null -w "%{http_code}\n" https://your-domain.com/wp-config.php
   # Expected: 403 (with an active block) or 200 with an empty body

3. Contrôler les permissions :

   ls -l wp-config.php
   # Expected: -rw------- (600) or -rw-r----- (640)

4. Dans l'administration, vérifiez qu'aucun éditeur n'apparaît plus sous Apparence et Extensions (effet de DISALLOW_FILE_EDIT).

Erreurs fréquentes

• Permissions trop strictes : Chez certains hébergeurs, PHP ne s'exécute pas comme propriétaire du fichier. 600 peut alors provoquer une erreur 500 – dans ce cas, utilisez 640 ou 644.
• Clés remplacées sans sauvegarde : Sauvegardez le fichier avant toute modification. Une faute de frappe dans les constantes met le site hors ligne.
• DISALLOW_FILE_MODS trop tôt : Cette constante bloque aussi les mises à jour normales d'extensions/thèmes via le tableau de bord. Ne l'activez que si les mises à jour passent exclusivement par déploiement/WP-CLI.
• Fichier déplacé, mais mauvais chemin : En le déplaçant hors du webroot, ne bricolez pas de chargeur require personnalisé qui expose un chemin serveur absolu.

Questions fréquentes (FAQ)

Quelle permission de fichier wp-config.php doit-elle avoir ?

600 est recommandé (seul le propriétaire peut lire et écrire). Si sur votre hébergeur PHP ne s'exécute pas comme propriétaire du fichier mais via le groupe, utilisez 640. Ne mettez jamais 777 ou 666, car alors n'importe quel utilisateur du serveur peut lire les identifiants de la base de données.

Que se passe-t-il si je change les clés de sécurité dans wp-config.php ?

Tous les utilisateurs connectés sont déconnectés et doivent se reconnecter. C'est voulu et un moyen efficace d'invalider les cookies de session volés. Le contenu du site reste inchangé. Générez des valeurs fraîches via le générateur officiel de clés secrètes de WordPress.

À quoi sert la constante DISALLOW_FILE_EDIT ?

DISALLOW_FILE_EDIT désactive l'éditeur de thèmes et d'extensions dans l'administration de WordPress. Sans cette constante, un attaquant qui prend le contrôle d'un compte administrateur peut exécuter du code PHP arbitraire directement via Apparence » Éditeur de thème. La constante est donc l'une des mesures de renforcement les plus importantes.

Dois-je déplacer wp-config.php hors du webroot ?

WordPress cherche aussi wp-config.php un niveau de répertoire au-dessus du webroot. Sur les installations classiques mono site avec un webroot dédié, le déplacer augmente la sécurité. Sur l'hébergement mutualisé, où plusieurs sites partagent le même niveau parent, cela peut provoquer des conflits – en cas de doute, vérifiez avec votre hébergeur.

Comment InspectWP aide-t-il avec wp-config.php ?

Lors du crawl, InspectWP vérifie entre autres si des fichiers sensibles comme wp-config.php ou une sauvegarde wp-config.php.bak sont accessibles publiquement, si l'administration est forcée en HTTPS et si des sorties de débogage fuitent vers l'extérieur. Les résultats correspondants sont signalés comme risque de sécurité dans le rapport.