# Autorisation

> Vérification des droits accordés à un utilisateur déjà identifié, pour déterminer s'il peut effectuer une action ou consulter une ressource donnée.

- Auteur : Clément Hadrot
- Publié le : 2026-09-25
- Mis à jour le : 2026-09-25
- URL : https://wpmoderne.dev.wordpress-developpement.fr/lexique/autorisation/

Ê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.