Les failles d'autorisation (IDOR, BOLA, BFLA) échappent aux scanners classiques. Comment l'investigation IA les détecte avec des preuves concrètes.
Jordan Fredj
25 janvier 2026
12 min
Loading...
Jordan Fredj
Fondateur, Hacksessible
Les failles d'autorisation représentent la menace la plus sous-estimee dans la sécurité des applications web et des APIs. IDOR (Insecure Direct Object Reference), BOLA (Broken Object Level Authorization), et BFLA (Broken Function Level Authorization) sont trois variantes d'un meme problème fondamental : l'application ne verifie pas correctement si l'utilisateur a le droit d'acceder a la ressource qu'il demande. Ces failles echappent systematiquement aux scanners de vulnérabilités classiques. Cet article explique en detail ce que sont ces failles, pourquoi elles sont si dangereuses, et comment l'investigation par IA les détecté la ou les outils traditionnels echouent.
Avant de plonger dans les details techniques, clarifions la difference fondamentale entre authentification et autorisation. L'authentification verifie l'identite de l'utilisateur : "qui etes-vous ?". L'autorisation verifie ses droits : "avez-vous le droit de faire cela ?". Une application peut avoir une authentification parfaite (mots de passe forts, MFA, tokens securises) tout en etant completement vulnerable aux failles d'autorisation si elle ne verifie pas les droits d'acces a chaque operation.
Les failles d'autorisation sont en première position du classement OWASP API Security Top 10, et pour cause : elles sont presentes dans une proportion alarmante d'applications, elles permettent souvent d'acceder a des donnees sensibles (donnees personnelles, donnees financieres, secrets commerciaux), et elles sont extremement difficiles a détectér avec des outils automatisés traditionnels.
L'IDOR est la forme la plus classique de faille d'autorisation. Elle survient lorsqu'une application utilise un identifiant fourni par l'utilisateur pour acceder directement a un objet en base de donnees, sans verifier que l'utilisateur a le droit d'acceder a cet objet spécifique.
Exemple concret : une application e-commerce utilise l'endpoint GET /api/orders/12345 pour afficher la commande numero 12345. L'utilisateur A, connecte a son compte, peut voir sa commande 12345. Mais que se passe-t-il s'il modifie l'URL en /api/orders/12346 ? Si l'application verifie uniquement que l'utilisateur est authentifie mais pas que la commande 12346 lui appartient, il peut acceder aux commandes d'autres clients. C'est un IDOR.
Les consequences d'un IDOR peuvent etre devastatrices : acces aux donnees personnelles de millions d'utilisateurs, consultation de documents confidentiels, modification de donnees d'autres comptes. Des incidents reels ont expose des dossiers medicaux, des releves bancaires, des contrats d'assurance, et bien d'autres donnees sensibles. L'impact est souvent amplifie par le fait que les identifiants sont sequentiels (1, 2, 3...) ou previsibles, permettant une enumeration systematique de tous les objets.
BOLA est essentiellement le meme concept que l'IDOR, mais formule dans le contexte des APIs modernes. Le terme BOLA est utilise par l'OWASP dans son API Security Top 10 (API1:2023 - Broken Object Level Authorization). C'est la vulnérabilité API la plus courante et la plus dangereuse.
Dans une architecture API moderne, BOLA se manifeste de multiples facons. Un utilisateur peut acceder aux ressources d'un autre utilisateur en manipulant l'identifiant dans l'URL (/api/users/{"{userId}"}/profile). Un tenant d'une application SaaS multi-tenant peut acceder aux donnees d'un autre tenant en modifiant le tenant ID dans les requetes. Un utilisateur peut acceder a des fichiers d'autres utilisateurs en devinant ou en enumerant les noms de fichiers ou les identifiants de stockage.
BFLA est une variante differente : au lieu d'acceder aux donnees d'un autre utilisateur (meme role, meme niveau de privilege), l'attaquant accede a des fonctionnalites reservees a un role superieur. C'est une escalade de privileges horizontale vers le vertical.
Exemple concret : une application SaaS a trois roles - utilisateur standard, manager, et administrateur. L'endpoint POST /api/admin/users/create est cense etre accessible uniquement aux administrateurs. Mais si l'application verifie le role uniquement cote frontend (en masquant le bouton "Creer un utilisateur" pour les non-admins) sans verification cote serveur, un utilisateur standard qui connait l'endpoint peut creer des comptes utilisateurs. Pire, il pourrait se creer un compte administrateur.
Les manifestations courantes de BFLA incluent l'acces a des endpoints d'administration sans etre administrateur, la modification de roles ou permissions d'autres utilisateurs, l'acces a des fonctionnalites de gestion (export de donnees, configuration système) reservees aux roles privilegies, et l'execution d'operations destructives (suppression, modification en masse) sans les privileges requis.
La raison pour laquelle les scanners de vulnérabilités classiques echouent a détectér IDOR, BOLA et BFLA est fondamentale : ces failles ne correspondent a aucun pattern technique detectable par signature. Il n'y a pas de code d'erreur spécifique, pas de comportement HTTP anormal, pas de CVE a chercher.
Pour détectér un IDOR, il faut comprendre le contexte : savoir qu'une ressource renvoyee par l'API appartient a un autre utilisateur. Cela nécessité deux sessions authentifiees (ou plus), une comprehension de la relation entre les identifiants et les utilisateurs, et la capacité de comparer les réponses pour determiner si des donnees non autorisees sont accessibles. Un scanner qui envoie des requetes avec un seul compte ne peut pas détectér un IDOR car la requete modifiee renvoie simplement des donnees valides - le scanner ne sait pas que ces donnees ne devraient pas etre accessibles.
Pour BFLA, le problème est similaire : le scanner doit savoir quelles fonctionnalites sont reservees a quels roles, et tester l'acces avec differents niveaux de privilege. Les scanners classiques ne font pas cette distinction - ils testent les endpoints de maniere uniforme sans notion de roles.
Les agents IA d'Hacksessible sont spécifiquement concus pour détectér les failles d'autorisation. Leur approche reproduit le raisonnement d'un pentester specialise en tests d'autorisation.
L'agent IA travaille avec plusieurs sessions simultanees representant differents niveaux de privilege (utilisateur standard, manager, admin, utilisateur d'un autre tenant). Il envoie les memes requetes depuis chaque session et compare les résultats. Si une requete envoyee depuis une session non privilegiee renvoie des donnees qui ne devraient etre accessibles qu'a une session privilegiee, c'est un IDOR ou un BOLA confirme. Cette approche multi-sessions est exactement ce que fait un pentester humain, mais l'IA peut le faire de maniere systematique sur des centaines d'endpoints.
L'agent IA analyse la structure des réponses API pour comprendre les relations entre les objets. Il identifié les identifiants (numeriques, UUID, slugs), les relations de propriete (cet objet appartient a quel utilisateur/tenant), et les patterns d'acces. Cette comprehension lui permet de formuler des hypotheses de BOLA pertinentes : "Si je remplace le user_id dans cette requete par celui d'un autre utilisateur, est-ce que j'obtiens ses donnees ?".
Pour BFLA, l'agent IA cartographie les endpoints accessibles a chaque role et tente d'acceder aux endpoints des roles superieurs avec des sessions de role inferieur. Il teste systematiquement les endpoints d'administration, de gestion, et de configuration avec des sessions utilisateur standard. Chaque acces reussi est documente avec une preuve complete : la requete envoyee, la session utilisee (et son role), la réponse recue, et l'impact de l'acces non autorise.
Les failles d'autorisation sont a l'origine de nombreuses violations de donnees majeures. Une plateforme de reservation en ligne a expose les donnees de reservation de tous ses clients via un IDOR sur l'endpoint /api/bookings/{"{id}"} - un simple changement d'identifiant numerique permettait d'acceder aux reservations d'autres clients, incluant noms, coordonnees et details de paiement. L'estimation de l'impact : plusieurs millions d'enregistrements accessibles.
Une plateforme SaaS B2B a subi une fuite de donnees cross-tenant via un BOLA sur son API de documents. Un utilisateur du tenant A pouvait acceder aux documents du tenant B en modifiant le document_id dans l'URL. La faille existait depuis le lancement du produit et n'avait jamais ete détectée par les scans de vulnérabilités reguliers.
Une application fintech a ete compromise via une BFLA : un utilisateur standard pouvait acceder a l'endpoint d'administration qui permettait de modifier les limites de transaction de n'importe quel compte. La verification du role etait implementee uniquement dans le frontend, pas dans l'API backend.
Conceptuellement oui. IDOR est le terme historique utilise dans le web classique. BOLA est le terme utilise par l'OWASP dans son API Security Top 10. Les deux decrivent le meme problème : un utilisateur authentifie peut acceder a des objets qui ne lui appartiennent pas en manipulant l'identifiant de l'objet.
Non. Les UUID rendent l'enumeration plus difficile mais ne protegent pas contre les IDOR. Si un attaquant obtient un UUID valide (par une fuite d'information, un log, ou un autre endpoint), il peut l'utiliser pour acceder a la ressource. La seule protection fiable est une verification d'autorisation cote serveur.
Creez deux comptes utilisateurs. Connectez-vous avec le compte A et notez les identifiants des ressources qui lui appartiennent. Connectez-vous avec le compte B et tentez d'acceder aux ressources du compte A en utilisant ses identifiants. Si vous obtenez les donnees du compte A depuis la session du compte B, c'est un IDOR. Repetez pour chaque type de ressource et chaque endpoint.
Non. Aucun framework web (Express, Django, Rails, Spring) ne protege automatiquement contre les failles d'autorisation. Les frameworks fournissent des outils d'authentification, mais l'autorisation est toujours de la responsabilite du developpeur. C'est pourquoi ces failles sont si frequentes : elles ne sont pas un bug technique mais un oubli de logique metier.
Jordan Fredj, Fondateur Hacksessible -
L'investigation par IA d'Hacksessible détecté les IDOR, BOLA et BFLA avec des preuves concretes. Testez sur votre application.