Une extension qui a besoin de signer une valeur temporaire — un jeton de désinscription, un lien de prévisualisation signé, un identifiant de session côté client — a besoin d’un secret. La solution la plus rapide, coder une chaîne fixe directement dans le code source de l’extension, est aussi la moins sûre : ce secret serait alors identique sur tous les sites qui installent cette extension, un client aussi bien qu’un attaquant qui aurait accès au code source public.
wp_salt() résout ce problème en s’appuyant sur les clés de sécurité définies dans le fichier wp-config.php de chaque installation, propres à chaque site et généralement générées de façon aléatoire à l’installation.
Ce que fait wp_salt()
La fonction retourne une chaîne dérivée des constantes de sécurité (AUTH_KEY, AUTH_SALT, etc.) et, en leur absence, d’une valeur de secours stockée en base de données. Un paramètre optionnel appelé scheme permet de cibler un jeu de clés particulier parmi ceux utilisés en interne par WordPress : auth, secure_auth, logged_in ou nonce.
$secret = wp_salt( 'auth' );
$jeton = hash_hmac( 'sha256', 'action_specifique_' . $user_id, $secret );
Ce jeton, propre à l’installation et à l’utilisateur concerné, peut ensuite être transmis dans une URL ou un formulaire pour vérifier plus tard qu’il n’a pas été altéré, sans jamais exposer le secret lui-même.
Pourquoi ne pas simplement utiliser une constante personnalisée
- Une constante définie par l’extension elle-même, avec une valeur par défaut codée en dur, expose ce secret dans le code source distribué, visible par quiconque installe l’extension.
- S’appuyer sur
wp_salt()garantit une valeur différente sur chaque site, sans configuration supplémentaire demandée à l’utilisateur final de l’extension. - Si les clés de sécurité sont régénérées (bonne pratique après un incident de sécurité suspecté), tous les jetons dérivés via
wp_salt()deviennent automatiquement invalides, ce qui est le comportement souhaité.
Ne pas confondre avec wp_generate_password
wp_generate_password() sert à générer un nouveau mot de passe ou une chaîne aléatoire à un instant donné, différente à chaque appel. wp_salt() a un usage différent : produire une valeur stable dans le temps, réutilisable pour vérifier qu’un jeton généré plus tôt n’a pas été modifié, tant que les clés de sécurité du site ne changent pas.
Les quatre schémas disponibles
| Schéma | Usage interne dans WordPress |
|---|---|
auth | Cookies d’authentification standard |
secure_auth | Cookies d’authentification en connexion sécurisée |
logged_in | Cookie de session utilisateur connecté |
nonce | Génération des nonces de sécurité |
Un principe à retenir pour toute extension distribuée à plusieurs clients : jamais de secret codé en dur dans le code source.
wp_salt()fournit une base fiable, déjà présente sur chaque installation, sans configuration supplémentaire à documenter.
En résumé
Signer un jeton temporaire ne demande pas nécessairement d’ajouter une nouvelle constante ou une option en base de données : wp_salt() exploite ce qui existe déjà sur chaque site WordPress. Ce réflexe évite un secret partagé entre installations, une faiblesse discrète mais réelle dans du code distribué publiquement.
