Dans un wp-config.php fraîchement installé, huit lignes intriguent souvent les développeurs qui débutent : une série de constantes nommées AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY, chacune accompagnée de son pendant _SALT. Elles ressemblent à du bruit aléatoire, et c’est précisément leur rôle : servir de sel cryptographique pour tout ce que WordPress signe en coulisses.
Ces clés ne protègent pas directement une base de données ni un mot de passe. Elles interviennent dans la fabrication des cookies d’authentification et des jetons de sécurité appelés nonces. Comprendre leur mécanique aide à savoir quand les renouveler sans casser l’expérience des visiteurs, et pourquoi les ignorer expose un site à des risques bien réels.
Ce que sont réellement ces clés
Chaque constante combine deux éléments : une clé (une phrase quelconque) et un salt (une chaîne aléatoire supplémentaire). Le cœur de WordPress les concatène avant de les faire passer dans une fonction de hachage. Le résultat sert de secret partagé, jamais transmis au navigateur, qui permet au serveur de vérifier qu’une donnée reçue a bien été émise par lui-même.
Le générateur officiel, accessible sur api.wordpress.org, produit un jeu de huit lignes prêtes à coller. Chaque site devrait avoir son propre jeu, distinct de celui de tous les autres sites hébergés sur le même serveur.
Leur rôle dans les cookies et les nonces
Quand un utilisateur se connecte, WordPress construit un cookie contenant son identifiant, une date d’expiration et une signature calculée à partir de LOGGED_IN_KEY et LOGGED_IN_SALT. À chaque requête suivante, la fonction wp_validate_auth_cookie() recalcule cette signature et la compare. Sans connaître la clé, impossible de fabriquer un cookie valide, même en devinant l’identifiant d’un administrateur.
NONCE_KEY et NONCE_SALT jouent un rôle voisin pour les nonces, ces jetons à usage limité qui accompagnent les formulaires d’administration et certains appels à l’API REST. La fonction wp_create_nonce() s’appuie dessus pour générer un jeton impossible à deviner sans les clés du site.
Renouveler les clés : effets et bonnes pratiques
Changer une clé invalide instantanément tous les cookies et nonces déjà émis. Concrètement :
- Tous les utilisateurs connectés, y compris les administrateurs, sont déconnectés au prochain chargement de page.
- Les formulaires ouverts dans un onglet depuis un moment (édition d’article, réglages) renverront une erreur de sécurité à la soumission.
- Les sessions de l’API REST basées sur les cookies sont également coupées.
Ce comportement, loin d’être un défaut, est justement l’intérêt d’une rotation : après une suspicion de fuite (sauvegarde exposée, dépôt de code partagé par erreur, ancien collaborateur ayant eu accès au serveur), renouveler les clés révoque d’un coup tous les accès actifs sans avoir à traquer chaque session individuellement.
Automatiser la rotation avec WP-CLI
Plutôt que de copier-coller depuis le générateur en ligne à chaque fois, WP-CLI expose une commande dédiée qui modifie directement le fichier :
wp config shuffle-saltsElle régénère les huit constantes en une seule opération, sans exposer les nouvelles valeurs dans un terminal partagé ni nécessiter de copier une réponse HTTP. Dans un contexte d’agence, cette commande s’intègre facilement à un script de réponse à incident, déclenché par exemple juste après un changement d’équipe ou une alerte de scanner de malware.
Une politique raisonnable consiste à programmer cette rotation à intervalle fixe, par exemple tous les six mois pour les sites sensibles, en plus d’un déclenchement immédiat en cas de doute.
Un piège fréquent : des clés partagées entre environnements
Sur des hébergements mutualisés bas de gamme ou lors d’un clonage rapide de production vers un environnement de test, il arrive que le même wp-config.php soit copié tel quel. Résultat : les deux environnements partagent des clés identiques, et un cookie valide sur l’un peut parfois être rejoué sur l’autre si la base de données et l’URL correspondent.
Sur chaque nouveau clonage de site, la génération d’un jeu de clés propre à l’environnement de destination fait partie de notre check-list, au même titre que le changement d’URL.
En résumé
Les clés et salts de WordPress ne sont pas un détail de configuration parmi d’autres : ce sont les secrets qui rendent les cookies d’authentification et les nonces impossibles à falsifier. Les générer proprement à l’installation, ne jamais les partager entre environnements, et savoir les renouveler en cas de doute avec wp config shuffle-salts forme un réflexe simple qui coûte une commande et rapporte une vraie tranquillité d’esprit.
