BOLA et IDOR, c'est la même chose ?
Presque. IDOR (Insecure Direct Object Reference) est le terme historique. BOLA (Broken Object Level Authorization) est le terme utilisé par l'OWASP API Security Top 10 depuis 2019. Le concept est identique : un utilisateur authentifié accède aux ressources d'un autre utilisateur en manipulant l'identifiant de la ressource dans la requête.
Pourquoi c'est si fréquent
Les frameworks web facilitent la création de routes CRUD. Un développeur crée GET /api/documents/:id et le contrôleur récupère le document par son ID. Mais la vérification que l'utilisateur connecté est autorisé à voir ce document est une étape manuelle. Aucun framework ne l'ajoute automatiquement. Il faut explicitement écrire if (document.userId !== currentUser.id) return 403.
Facteur aggravant : les identifiants séquentiels. Si les IDs sont 1, 2, 3, 4..., l'attaquant peut tous les énumérer. Les UUID réduisent le risque d'énumération mais ne remplacent pas le contrôle d'autorisation.
Techniques d'exploitation
Énumération directe
L'attaquant parcourt une plage d'IDs : GET /api/users/1, GET /api/users/2, etc. Avec un script automatisé, des milliers de profils sont extraits en quelques minutes.
Manipulation de paramètres
Changer user_id dans le body d'une requête POST ou PATCH. Si POST /api/transfer accepte {"from_account": "attacker", "to_account": "victim", "amount": 1000} sans vérifier que l'appelant possède le compte source, c'est un BOLA critique.
GraphQL et nested queries
En GraphQL, un attaquant peut naviguer dans les relations : query { user(id: 42) { documents { content } } }. Si la résolution du type User ne vérifie pas l'autorisation, les documents de n'importe quel utilisateur sont accessibles.
Via les fichiers et médias
Les URLs de téléchargement avec des IDs prévisibles : /api/files/invoice_1042.pdf. L'attaquant modifie le numéro de facture pour accéder aux documents d'autres clients.
Défenses
Impact réel
Les BOLA permettent l'exfiltration massive de données personnelles. En termes RGPD, c'est une violation de données à notifier à la CNIL sous 72 heures. Chez CleanIssue, nous identifions des BOLA dans environ 40% des API auditées. Parlez-nous de votre revue externe.
Articles liés
Trois analyses proches pour continuer la lecture sur la meme surface de risque.
Vulnérabilités API et webhooks : le guide 2026 des erreurs qui exposent vraiment les données
Guide de référence sur les erreurs API et webhook qui créent de vrais risques : BOLA, mass assignment, flows sensibles, signatures HMAC, docs trop bavardes et callbacks trop confiants.
OWASP API Top 10 : les 10 failles d'API à connaître en 2026
Analyse des 10 vulnérabilités API les plus critiques selon l'OWASP API Security Top 10 2023, avec des cas pratiques pour chaque catégorie.
GraphQL : 5 attaques spécifiques que les scanners ratent
Les vulnérabilités propres à GraphQL que les outils automatisés ne détectent pas : introspection, batching, deep queries, aliases et injections.
Sources
Analyse éditoriale fondée sur la documentation officielle des éditeurs, projets et autorités concernées.
Services associés
Si ce sujet reflète un risque concret sur votre stack, voici les audits CleanIssue les plus pertinents.