Une API relie des applications et expose des opérations sur des données. Un utilisateur correctement authentifié ne doit pas pour autant pouvoir consulter ou modifier toutes les ressources disponibles.
Comprendre le défaut d’autorisation
L’OWASP décrit le risque de contrôle d’accès insuffisant au niveau des objets : le serveur reçoit un identifiant de ressource sans vérifier correctement le droit de l’utilisateur à réaliser l’action demandée. Des identifiants difficiles à deviner ne remplacent pas cette vérification.
Définir les règles côté serveur
Pour chaque opération, précisez quels rôles peuvent agir, sur quelles ressources et dans quel contexte. La lecture, la modification et la suppression peuvent demander des règles différentes. Masquer un bouton dans l’interface ne constitue pas un contrôle suffisant.
Préparer des tests autorisés
Exemple fictif : un portail de documents comporte deux comptes de test appartenant à deux clients distincts. Dans un environnement prévu pour l’audit, vérifiez que chaque compte ne peut lire et modifier que ses propres ressources. Les essais doivent rester dans le périmètre autorisé.
Le regard Aztechnix
Ajoutez ces vérifications aux tests de non-régression et documentez les exceptions métier. Les accès délégués et les comptes de support demandent une attention particulière : leurs droits peuvent être plus larges, mais doivent rester explicites. L’objectif est de faire respecter la séparation entre clients et entre fonctions à chaque requête, même lorsque l’utilisateur connaît l’identifiant exact d’une autre ressource.
Source et méthode
OWASP — API1:2023 Broken Object Level Authorization. Source consultée le 1er novembre 2026. Synthèse et recommandations pratiques : Aztechnix. Les mises en situation sont fictives ; elles ne constituent pas des références clients.