Bob se connecte à l’API du laboratoire avec son propre compte valide, effectue une requête GET /invoices/inv_100 et reçoit la facture d’Alice. L’attaquant n’a ni volé de jeton, ni contourné la connexion, ni deviné de mot de passe. Bob a modifié un identifiant d’objet dans une route, modification acceptée par le serveur sans vérification de l’appartenance de inv_100 à Bob. La question qui se pose pour le défenseur est donc plus ciblée — et plus utile — que celle de savoir si la connexion fonctionne : pour chaque requête, l’API vérifie-t-elle que l’entité authentifiée est autorisée à effectuer cette opération sur cet objet ?
L’artefact que nous utilisons est une petite API REST comprenant les points de terminaison suivants : POST /login, GET /invoices/{invoiceId}, PUT /invoices/{invoiceId} et GET /admin/audit. Alice est propriétaire de inv_100, Bob de inv_200, et un administrateur peut lire les journaux d’audit. Un modèle de menaces identifie les éléments déjà contrôlés par l’attaquant, la frontière franchie par la requête, les intentions de l’attaquant et la décision du serveur devant bloquer la requête. Ici, Bob contrôle sa requête authentifiée ainsi que l’identifiant invoiceId ; il cherche à obtenir la facture d’Alice ; le mécanisme d’autorisation doit donc refuser l’accès avant que les données ne quittent le stockage.
L’authentification établit que la requête provient bien de Bob. Il reste toutefois à déterminer, via l’autorisation, si Bob est habilité à lire inv_100. Regrouper ces décisions en une seule vérification est source de vulnérabilité, car une identité valide ne renseigne en rien sur la propriété de l’objet ou sur les privilèges d’administration. Tout au long de ce cours, notre objectif sera de renforcer cette API et de démontrer la robustesse de chaque frontière lors des tests. Le schéma ci-dessous localise les frontières franchies par Bob.
Ce schéma illustre pourquoi une requête peut franchir l’étape de l’authentification tout en échouant lors de l’autorisation ou de l’accès aux données. L’identifiant d’objet ne présente un risque que lorsque l’API l’utilise pour récupérer un enregistrement sans associer cet enregistrement à l’entité authentifiée.
L’absence de vérification de propriété correspond à la vulnérabilité API1:2023 Broken Object Level Authorization (BOLA, ou autorisation défaillante au niveau de l’objet) du classement OWASP API Security Top 10 2023. Tout point de terminaison (endpoint) acceptant un identifiant d’objet contrôlé par le client nécessite une décision d’autorisation spécifique à cet objet. Les opérations GET /invoices/inv_100 et PUT /invoices/inv_100 étant distinctes, chacune requiert sa propre décision, même si elles visent toutes deux la même facture.
Les autres risques initiaux gravitent autour du même chemin de requête. API2:2023 (Broken Authentication) porte sur la capacité de l’API à identifier correctement Bob. API3:2023 (Broken Object Property Level Authorization) concerne le risque qu’une réponse autorisée concernant une facture expose ou accepte des champs auxquels Bob ne devrait pas avoir accès, comme un champ interne approvalLimit (limite d’approbation). API4:2023 (Unrestricted Resource Consumption) traite du cas où Bob envoie des requêtes coûteuses en ressources, suffisamment souvent pour saturer la capacité du système ou déclencher des traitements en aval facturables. Enfin, API5:2023 (Broken Function Level Authorization) concerne l’accès par Bob au point de terminaison GET /admin/audit alors qu’il ne dispose pas des droits d’administration requis.
Chaque catégorie implique une modification différente de la requête, mais toutes visent à vérifier si le serveur impose une limite de sécurité au lieu de se fier aveuglément aux données fournies par le client, à un simple jeton ou au nom du point de terminaison. Le tableau met en balance la modification effectuée par l’attaquant, l’élément à protéger et les preuves nécessaires aux défenseurs.