Comprendre les nonces WordPress : à quoi ils servent vraiment

Le mot « nonce » revient sans cesse dans le code WordPress, dans la documentation des hooks, dans les avertissements du Plugin Check, et pourtant beaucoup de développeurs qui l’utilisent au quotidien ne savent pas précisément ce qu’il protège. Ce n’est pas un détail : mal comprendre les nonces conduit soit à des vérifications inutiles qui n’apportent rien, soit pire, à une fausse impression de sécurité.

Un nonce (« number used once », même si en pratique il peut être vérifié plusieurs fois pendant sa durée de vie) est un jeton généré par WordPress pour vérifier qu’une action provient bien d’un formulaire ou d’un lien légitimement affiché par le site, et non d’une requête forgée depuis l’extérieur. C’est la brique de base de la protection contre les attaques CSRF (Cross-Site Request Forgery) dans l’écosystème WordPress.

Générer un nonce dans un formulaire

La fonction la plus courante pour insérer un nonce dans un formulaire d’administration est wp_nonce_field(), qui génère directement un champ caché :

<form method="post" action="">
    <?php wp_nonce_field( 'mon_plugin_save_options', 'mon_plugin_nonce' ); ?>
    <input type="text" name="mon_champ" />
    <input type="submit" value="Enregistrer" />
</form>

Le premier paramètre, l’« action », est une chaîne qui identifie précisément ce que ce nonce autorise. Il est essentiel de la rendre spécifique au contexte (par exemple en y intégrant un identifiant d’article) plutôt que de réutiliser une action générique pour tout le site, sans quoi un nonce valide pour une action pourrait être rejoué pour une autre.

Vérifier un nonce côté serveur

Trois fonctions principales permettent de vérifier un nonce, selon le contexte :

• wp_verify_nonce( $nonce, 'action' ) renvoie 1, 2 ou false, à tester explicitement plutôt qu’avec une simple comparaison booléenne ;
• check_admin_referer( 'action', 'nom_du_champ' ) vérifie le nonce et l’en-tête Referer, et arrête l’exécution avec wp_die() si la vérification échoue ;
• check_ajax_referer( 'action', 'nom_du_champ' ) fait l’équivalent pour les requêtes AJAX envoyées vers admin-ajax.php.

function mon_plugin_save_options() {
    if ( ! isset( $_POST['mon_plugin_nonce'] )
        || ! wp_verify_nonce( $_POST['mon_plugin_nonce'], 'mon_plugin_save_options' ) ) {
        wp_die( 'Vérification de sécurité échouée.' );
    }

    if ( ! current_user_can( 'manage_options' ) ) {
        wp_die( 'Action non autorisée.' );
    }

    // Traitement des données, une fois les deux vérifications passées.
}

Remarquez l’ordre des vérifications dans cet exemple : le nonce est vérifié en premier, mais la capacité de l’utilisateur l’est aussi, séparément. C’est un point que beaucoup de développeurs négligent, et j’y reviens plus bas.

Durée de vie et pourquoi elle compte

Un nonce WordPress n’est pas strictement « à usage unique » malgré son nom. Il reste valide pendant une fenêtre de temps calculée à partir de la constante DAY_IN_SECONDS, avec un système à deux valeurs (« tick ») qui fait qu’un nonce reste en pratique valable entre 12 et 24 heures dans la première fenêtre, puis encore autant dans une seconde fenêtre de tolérance, soit une validité effective pouvant aller jusqu’à 24 à 48 heures selon le moment de sa génération. C’est pour cela qu’un formulaire laissé ouvert dans un onglet la veille peut encore fonctionner le lendemain matin.

Erreurs fréquentes à éviter

Sur les audits de code que je mène, les mêmes erreurs reviennent régulièrement :

• Confondre nonce et authentification : un nonce ne prouve pas qui est l’utilisateur, seulement que la requête provient d’une page où WordPress l’a généré pour la session courante ;
• Oublier de vérifier current_user_can() en plus du nonce, en pensant que le nonce suffit à sécuriser une action sensible ;
• Utiliser une action de nonce trop générique, réutilisée pour plusieurs formulaires différents ;
• Tester le retour de wp_verify_nonce() avec === true plutôt que de vérifier simplement qu’il n’est pas false, ce qui fait échouer la vérification à tort puisque la fonction renvoie 1 ou 2 en cas de succès.

Un nonce répond à la question « cette requête vient-elle bien d’un formulaire que j’ai généré ? », jamais à la question « cet utilisateur a-t-il le droit de faire ça ? ». Je le rappelle à chaque revue de code : les deux vérifications sont complémentaires, jamais interchangeables.

Pour aller plus loin

Les nonces sont une protection élégante et peu coûteuse contre le CSRF, mais ils ne constituent qu’une moitié du dispositif de sécurité d’une action sensible dans WordPress. L’autre moitié, la vérification des capacités avec current_user_can(), mérite un article à elle seule tant les pièges y sont nombreux. Retenez pour l’instant cette règle simple : chaque formulaire ou requête AJAX qui modifie une donnée doit vérifier à la fois un nonce et une capacité, jamais l’un sans l’autre.