Être authentifié ne veut pas dire pouvoir tout faire : un abonné connecté et un administrateur connecté ont tous deux prouvé leur identité, mais leurs droits n’ont rien de comparable. L’autorisation intervient après l’authentification, au moment précis où le système décide si l’action demandée est permise à cette personne précise.
Fonctionnement dans WordPress
WordPress s’appuie sur un système de rôles (administrateur, éditeur, auteur…) composés de capacités individuelles comme edit_posts ou manage_options. La fonction current_user_can() vérifie qu’une capacité précise est bien accordée à l’utilisateur courant avant d’exécuter une action sensible, ce qui doit systématiquement précéder toute opération d’écriture déclenchée depuis l’administration.
Exemple
if (!current_user_can('manage_options')) {
wp_die(__('Action non autorisée.', 'wpm'));
}
update_option('wpm_cle_api', $nouvelle_cle);
Pièges fréquents
Vérifier le rôle d’un utilisateur (current_user_can('administrator')) plutôt qu’une capacité précise est une pratique déconseillée : elle rend le code rigide si les rôles évoluent, alors que vérifier la capacité exacte requise reste valable même si les permissions sont redistribuées autrement par la suite. Oublier ce contrôle sur un point de terminaison de l’API REST personnalisé est l’une des causes les plus fréquentes de failles de sécurité dans les extensions WordPress, en particulier quand le développeur suppose à tort qu’un simple contrôle de nonce suffit à protéger l’action.