Nonce

Le mot vient de l’anglais « number used once ». En cryptographie, MDN le définit comme une valeur arbitraire employée une seule fois dans une communication, pour empêcher qu’un message intercepté soit rejoué, garantir qu’une réponse est fraîche ou ajouter de l’aléa à un calcul. Sur le web, le terme recouvre pourtant deux réalités assez différentes, qu’il vaut mieux ne pas confondre : le nonce cryptographique « pur » et le nonce de WordPress.

Les usages du nonce sur le web

• Dans les protocoles : les échanges de TLS et de nombreux mécanismes d’authentification intègrent des valeurs aléatoires à usage unique pour qu’une conversation enregistrée ne puisse pas être rejouée telle quelle.
• Dans une Content Security Policy : le serveur génère une valeur aléatoire à chaque réponse, la place dans la directive script-src 'nonce-…' et dans l’attribut nonce des scripts autorisés. Une CSP stricte n’exécute que les scripts qui portent la bonne valeur. MDN insiste : elle doit changer à chaque réponse et rester imprévisible.
• Contre les requêtes forgées : un jeton secret ajouté aux formulaires prouve que la requête vient bien d’une page du site, ce qui bloque les attaques CSRF. C’est le rôle principal des nonces de WordPress.

Les nonces de WordPress : pas vraiment des nonces

La documentation officielle de WordPress le reconnaît elle-même : ses nonces ne sont ni des nombres ni à usage unique. La fonction wp_create_nonce() calcule une empreinte de dix caractères à partir de l’action demandée, de l’identifiant de l’utilisateur, de son jeton de session et d’une période de temps. Le calcul utilise les clés NONCE_KEY et NONCE_SALT du fichier wp-config.php, d’où l’importance de leur sel unique.

• Durée de vie : un jour par défaut, découpé en deux périodes de 12 heures. Selon le moment où il a été créé, un nonce reste donc valable entre 12 et 24 heures. Le filtre nonce_life change cette durée.
• Réutilisable : WordPress ne vérifie pas qu’un nonce n’a servi qu’une fois. Il ne protège donc pas contre le rejeu pendant sa durée de validité.
• Visiteurs non connectés : leur identifiant vaut 0, si bien que tous les visiteurs anonymes peuvent recevoir le même nonce pour une même action.

Pour WordPress : bien utiliser les nonces

Pour un développeur de thème ou d’extension, la règle tient en trois fonctions et une vérification de droits :

// Dans le formulaire
wp_nonce_field( 'supprimer_post_' . $post_id );

// Au traitement
check_admin_referer( 'supprimer_post_' . $post_id );
if ( ! current_user_can( 'delete_post', $post_id ) ) {
    wp_die( 'Action non autorisée.' );
}

• check_admin_referer() vérifie le nonce et le référent sur les écrans d’administration, check_ajax_referer() le nonce seul pour les requêtes AJAX, wp_verify_nonce() dans les autres cas.
• Nommez l’action précisément (avec l’identifiant de l’objet) plutôt qu’un nom générique partagé par tout le site.
• Ne vous fiez jamais au nonce pour l’autorisation : la documentation demande de protéger chaque fonction par current_user_can().

Erreurs fréquentes

Une bonne partie des failles d’extensions recensées chaque année vient d’un nonce absent ou d’une vérification de capacité oubliée, comme le montre notre article sur les failles des extensions WordPress en chiffres. Le cas typique : une action AJAX vérifie le nonce, mais pas le droit de l’utilisateur. Or un nonce peut fuir dans le code d’une page publique ; s’il est la seule barrière, un simple abonné peut parfois déclencher une action d’administrateur, ce qui mène à une élévation de privilèges. Notre guide des rôles et capacités WordPress détaille la logique du moindre privilège.

Autre piège : une page mise en cache plus de 12 à 24 heures sert un nonce périmé, et le formulaire échoue avec le message « Le lien suivi est expiré ». Excluez du cache les pages qui contiennent des formulaires réservés aux utilisateurs connectés.