BOLA : la vulnérabilité d’API qui se cache à la vue de tous

Imaginez que vous vous connectiez à votre application bancaire en ligne et que vous voyiez le solde de votre compte, l’historique de vos transactions et vos informations personnelles. Tout fonctionne exactement comme prévu. Imaginez maintenant que vous modifiiez un seul chiffre dans l’URL (l’identifiant du compte) et que vous puissiez soudain consulter les données financières d’une autre personne. Aucun outil de piratage. Aucun enchaînement d’exploits sophistiqué. Juste un chiffre.

Ce n’est pas un scénario hypothétique. C’est exactement le type de vulnérabilité qui a permis à T-Mobile d’exposer les données de 37 millions de clients lors d’une violation divulguée en 2023, qui a finalement donné lieu à un accord transactionnel de 350 millions de dollars dans le cadre d’une action collective.

C’est la même catégorie de faille qui a permis à des attaquants d’accéder aux données personnelles et aux statistiques d’entraînement de n’importe quel utilisateur de Peloton, en changeant simplement les identifiants d’utilisateur dans les requêtes API. Et c’est le même type de vulnérabilité qui, dans Harbor (un registre de conteneurs largement utilisé), a permis à un utilisateur disposant d’un rôle Maintenance de base de rendre public un projet privé entier et de déployer des images non vérifiées en modifiant les métadonnées du projet au moyen d’un appel API non autorisé.

La vulnérabilité au cœur de tous ces incidents porte un nom : Broken Object Level Authorization (BOLA). Elle occupe la 1re place de l’OWASP API Security Top 10 et est sans doute la faille la plus répandue, la plus dangereuse et la plus sous-estimée de la sécurité des API modernes.

Qu’est-ce que la BOLA ?

La Broken Object Level Authorization est une faille d’autorisation : une API ou une application web ne vérifie pas si l’utilisateur qui envoie une requête a le droit d’accéder à l’objet de données ciblé ou de le modifier. Lorsqu’un utilisateur demande une ressource, comme un enregistrement de base de données, un fichier ou une transaction, l’application doit vérifier non seulement que l’utilisateur est authentifié (qu’il est bien celui qu’il prétend être), mais aussi qu’il est autorisé à interagir avec cet objet précis (qu’il a le droit de le consulter ou de le modifier).

Lorsque cette vérification d’autorisation est absente, insuffisante ou appliquée de manière incohérente, un attaquant peut accéder aux données d’autres utilisateurs en modifiant simplement l’identifiant de l’objet dans la requête. Changer un numéro de compte dans un paramètre d’URL. Remplacer un identifiant utilisateur dans un en-tête API. Modifier l’identifiant d’une ressource dans une charge utile JSON. Si le serveur ne vérifie pas la propriété de l’objet à chaque requête, il divulgue des données qu’il ne devrait pas transmettre.

Il est important de distinguer ce problème de l’authentification. L’authentification répond à la question « qui êtes-vous ? » et vérifie l’identité au moyen d’identifiants, de jetons ou de mécanismes multifacteurs. L’autorisation répond à la question « que pouvez-vous faire ? » et détermine les ressources et les actions auxquelles cette identité peut accéder. La BOLA exploite une défaillance de cette seconde vérification. L’utilisateur est authentifié, connecté et vérifié. Il accède simplement à des objets qui ne lui appartiennent pas, sans que l’application ne l’en empêche.

BOLA et IDOR : une même faille, deux perspectives

Si vous travaillez depuis quelque temps dans la sécurité des applications, vous aurez remarqué que la BOLA, telle que définie par l’OWASP, ressemble beaucoup à une autre vulnérabilité bien connue : les Insecure Direct Object References (IDOR). Ce sujet suscite de véritables débats dans la communauté de la cybersécurité, et la similarité des noms est source de confusion. Il mérite donc d’être clarifié.

Les IDOR trouvent leur origine dans l’OWASP Web Application Security Top 10, où elles apparaissent dès 2007. Le terme décrit un type d’attaque précis : une application expose une référence directe à un objet interne, comme une clé de base de données, un nom de fichier ou un identifiant séquentiel, et un attaquant modifie cette référence pour accéder à un élément auquel il ne devrait pas avoir accès. Les IDOR mettent principalement l’accent sur le mécanisme de l’exploit : l’identifiant prévisible, devinable ou énumérable que l’attaquant manipule.

Introduite dans l’OWASP API Security Top 10 en 2019, la BOLA décrit la même faille fondamentale, mais sous un angle plus large. Là où les IDOR se concentraient sur la référence manipulable, la BOLA reformule le problème pour désigner sa véritable nature : une vérification d’autorisation défaillante au niveau de l’objet.

L’accent passe du vecteur d’attaque (« la référence n’est pas sécurisée ») à la cause profonde (« l’autorisation est défaillante »). La BOLA reconnaît également explicitement que ces failles ne se limitent pas à la simple manipulation d’URL : elles peuvent apparaître dans le corps des requêtes API, les en-têtes, les graphes d’objets imbriqués et les échanges entre microservices, où la logique d’autorisation peut être appliquée de manière incohérente.

En pratique, les deux termes désignent la même famille de vulnérabilités. Que vous parliez d’IDOR ou de BOLA, le problème fondamental est identique : une application fait confiance aux identifiants fournis par l’utilisateur sans effectuer de vérification d’autorisation adéquate côté serveur sur l’objet demandé. Les mesures de protection sont les mêmes. Les conséquences pour l’entreprise aussi.

Cette distinction terminologique a toutefois son importance, pour deux raisons :

• Premièrement, la BOLA est un cadre de réflexion plus utile pour les architectures modernes pilotées par les API, car elle place la logique d’autorisation au centre du débat plutôt qu’un modèle technique particulier. À l’ère des microservices, des architectures composables et des écosystèmes d’API de plus en plus complexes, il est plus pertinent de penser l’autorisation de manière globale — pour chaque point de terminaison et chaque objet — que de se demander si un paramètre d’URL est devinable.

• Deuxièmement, la BOLA occupant la 1re place de l’OWASP API Security Top 10 et les IDOR relevant de la catégorie plus large « Broken Access Control » de l’OWASP Web Application Top 10, employer correctement les deux termes montre que vous comprenez toute l’étendue du problème, dans les contextes web comme API.

Dans la suite de cet article, nous utiliserons principalement le terme BOLA. Mais lorsque vous le rencontrerez, gardez à l’esprit que les IDOR font partie du même problème.

Pourquoi la BOLA est particulièrement dangereuse

La BOLA occupe une place particulièrement périlleuse dans le paysage des vulnérabilités, car elle réunit trois caractéristiques rarement associées : elle est facile à exploiter, difficile à détecter et ses conséquences sont dévastatrices.

Facile à exploiter.

Les attaques BOLA ne nécessitent ni outils sophistiqués, ni compétences techniques avancées, ni chaînes d’exploits complexes. Un attaquant peut rechercher ces vulnérabilités avec un simple navigateur, un outil proxy ou un script élémentaire. Il modifie un paramètre et observe la réponse. Si des données qui ne devraient pas être accessibles lui sont renvoyées, l’application est vulnérable. Le seuil d’entrée est pratiquement nul, ce qui rend ces failles exploitables par un éventail d’acteurs malveillants bien plus large que pour la plupart des autres catégories de vulnérabilités.

Difficile à tester. 

Les méthodes traditionnelles de tests de sécurité peinent à détecter la BOLA, car il ne s’agit pas de failles techniques au sens classique, mais d’erreurs de logique. Une injection SQL laisse des traces détectables dans une requête. Une vulnérabilité de Cross-Site Scripting (XSS) produit des charges utiles reconnaissables. À l’inverse, la BOLA repose sur une requête API parfaitement formée et syntaxiquement correcte, qui renvoie simplement des données appartenant au mauvais utilisateur. Aucune entrée malformée, aucune charge utile suspecte, aucun schéma anormal. La requête semble légitime. La réponse semble légitime. Le seul problème, c’est que la personne qui a envoyé la requête n’aurait pas dû recevoir cette réponse.

Capable de contourner les défenses modernes. 

Même les organisations dotées d’une posture de sécurité mature — pare-feu applicatifs web, passerelles API, limitation du débit et contrôles d’authentification — peuvent être vulnérables à la BOLA. Ces défenses sont conçues pour détecter les accès non autorisés, les requêtes malformées et les schémas d’attaque connus. La BOLA s’inscrit entièrement dans le cadre d’un trafic normal et authentifié. L’utilisateur dispose d’identifiants valides. Le format de la requête est correct. La passerelle API voit un utilisateur authentifié envoyer une requête apparemment légitime. Rien ne déclenche d’alerte.

Les conséquences pour l’entreprise sont à la mesure de la gravité : des violations de données exposant des millions d’enregistrements, des sanctions réglementaires, des recours collectifs et des atteintes à la réputation qui prennent des années à réparer. Quand une attaque se résume à changer un chiffre dans une URL, la question n’est pas de savoir si les attaquants vont essayer, mais si vos applications sauront les arrêter.

Quelles sont les causes de la BOLA ?

Les vulnérabilités BOLA résultent rarement d’une seule erreur d’ingénierie. Elles découlent généralement d’un ensemble d’hypothèses profondément erronées sur la conception, le développement et la maintenance des API.

Les développeurs s’appuient souvent trop sur les contrôles côté client et supposent que les utilisateurs ne manipuleront pas les identifiants d’objet ou les jetons. C’est une hypothèse fondamentalement erronée, comme le démontrent à maintes reprises les exemples de violations ci-dessus. Par ailleurs, la logique d’autorisation est souvent mise en œuvre de manière incohérente d’un point de terminaison à l’autre. En l’absence d’un cadre d’autorisation centralisé — lorsque chaque point de terminaison implémente ses propres contrôles d’accès, ou les oublie — des failles sont inévitables. Une application peut appliquer correctement les règles d’autorisation sur 99 points de terminaison sur 100. Celui qui a été oublié devient la porte d’entrée.

Les pratiques de test aggravent le problème. Les tests de sécurité manuels et l’automatisation à couverture limitée détectent rarement la BOLA, car il ne s’agit pas de vulnérabilités reposant sur des motifs. Impossible de les trouver en recherchant des signatures connues. Pour détecter efficacement la BOLA, il faut comprendre la logique métier, la propriété des données et le contexte de chaque requête — des capacités qui ont longtemps échappé aux outils automatisés.

À cela s’ajoute la réalité du développement logiciel moderne : la rapidité prime. Les équipes de développement subissent une pression constante pour livrer rapidement des API et répondre aux besoins de l’entreprise. La validation des autorisations est donc souvent reléguée au second plan au profit de la livraison de nouvelles fonctionnalités. La vulnérabilité BOLA qui découle de cet arbitrage peut rester indétectée pendant des mois, voire des années, jusqu’à ce qu’un attaquant la découvre.

Le défi de la détection

Détecter la BOLA à grande échelle est l’un des défis les plus difficiles de la sécurité des applications. Il est utile de comprendre pourquoi.

Le principal défi tient au fait qu’une détection efficace de la BOLA nécessite une compréhension du contexte. Le scanner doit savoir non seulement qu’une API renvoie des données, mais aussi si l’utilisateur qui envoie la requête précise est autorisé à y accéder. Cette ressource est-elle publique ou privée ? L’utilisateur qui en fait la demande en est-il le propriétaire ? Un utilisateur doté de ce rôle doit-il pouvoir consulter ce champ ? Ces questions dépendent entièrement de la logique métier et des règles d’autorisation de l’application. Il est impossible d’y répondre par comparaison de motifs ou détection fondée sur des signatures.

Les approches simples de détection de la BOLA, comme vérifier si la modification d’un identifiant renvoie des données différentes, génèrent un nombre inacceptable de faux positifs. De nombreuses API fournissent volontairement des ressources publiques accessibles à tous les utilisateurs authentifiés. Catalogue de produits, profil public, document partagé : ces ressources sont censées être accessibles à plusieurs utilisateurs. Signaler comme problème BOLA potentiel chaque cas où deux utilisateurs peuvent accéder à la même ressource génère un tel volume de bruit qu’il masque les véritables alertes. Les équipes AppSec, déjà débordées, ne peuvent pas se permettre d’examiner des centaines de faux positifs pour trouver quelques véritables défaillances d’autorisation.

C’est pourquoi certains concurrents qui prétendent détecter la BOLA n’obtiennent que des résultats superficiels. Sans la capacité de comprendre le contexte de l’accès et de déterminer si celui-ci devrait être restreint, les mécanismes de détection restent naïfs et le rapport signal/bruit demeure médiocre.

Pourquoi le problème est plus important que jamais

L’urgence de détecter la BOLA n’a rien de théorique. Plusieurs facteurs convergents rendent cette catégorie de vulnérabilités plus fréquente et plus dangereuse que jamais.

1. La surface d’attaque des API s’étend. 

Les applications modernes ne sont plus des bases de code monolithiques : elles se composent de microservices qui communiquent par des API, tandis que les architectures composables remplacent les anciens monolithes. Chaque nouveau microservice, chaque nouveau point de terminaison d’API, chaque nouvelle intégration constitue un point d’exposition potentiel à une vulnérabilité BOLA. Le nombre de points de terminaison d’API dans un environnement d’entreprise classique a augmenté de plusieurs ordres de grandeur, et la logique d’autorisation doit être correctement mise en œuvre pour chacun d’eux.

2. Le code généré par l’IA aggrave le problème. 

76 % des développeurs utilisent ou prévoient d’utiliser des outils de programmation basés sur l’IA (Stack Overflow, 2024), et une étude portant sur cinq grands modèles d’IA a révélé qu’au moins 48 % des extraits de code qu’ils ont générés contenaient des vulnérabilités. À mesure que le code est généré à la vitesse d’une machine, la surface d’exposition aux erreurs d’autorisation s’accroît en conséquence. Les développeurs qui travaillent avec des assistants de programmation IA livrent davantage de code, plus rapidement, mais la qualité de la logique d’autorisation de ce code dépend entièrement des instructions et des processus de revue qui l’encadrent. Dans bien des cas, le code généré fonctionne, mais omet les vérifications d’autorisation qu’un développeur soucieux de la sécurité aurait mises en œuvre.

3. Les agents d’IA créent de nouveaux vecteurs d’exposition. 

L’essor des agents d’IA autonomes qui interagissent avec des données et services internes par le biais d’API ajoute une nouvelle dimension au problème. Ces agents communiquent par les mêmes points de terminaison d’API que ceux utilisés par les utilisateurs humains, mais ils fonctionnent à la vitesse d’une machine et peuvent enchaîner plusieurs appels d’API, contrairement aux habitudes d’utilisation humaines. Si ces points de terminaison d’API présentent des vulnérabilités BOLA, un agent peut être détourné à des fins malveillantes — ou un attaquant peut exploiter les mêmes points de terminaison que l’agent — pour exfiltrer des données ou modifier des ressources à grande échelle.

Un agent qui utilise une API compromise par une vulnérabilité BOLA n’est pas une simple vulnérabilité : c’est une machine d’exfiltration de données automatisée.

Quatre des cinq premières entrées du Top 10 des risques de sécurité des API de l’OWASP concernent l’autorisation et l’authentification. BOLA n’est pas un problème isolé : c’est le symptôme le plus visible d’un défi systémique lié à la gestion des contrôles d’accès dans les applications modernes. Détecter les vulnérabilités BOLA ouvre la voie à la prise en charge d’un ensemble plus vaste de failles d’autorisation, qui représentent la majorité des risques critiques pour la sécurité des API.

Une nouvelle approche : la détection de BOLA par l’IA

Le défi de détection qui rend les vulnérabilités BOLA si persistantes tient fondamentalement à la compréhension du contexte. C’est précisément là que les progrès récents de l’IA et des grands modèles de langage (LLM) changent la donne.

L’approche mise au point par Snyk API & Web s’appuie sur les LLM pour analyser le contexte des requêtes API et la logique d’autorisation. Elle va au-delà des techniques DAST traditionnelles pour déterminer à qui appartient le contenu et si l’utilisateur à l’origine de la requête devrait pouvoir accéder à la réponse. Au lieu de s’appuyer sur de simples heuristiques d’échange d’identifiants, qui génèrent des faux positifs, le moteur de détection basé sur l’IA peut évaluer si les données sont publiques ou privées, si l’utilisateur à l’origine de la requête en est le propriétaire légitime et si la limite d’autorisation a réellement été franchie.

Il ne s’agit pas de remplacer les principes fondamentaux des tests dynamiques de sécurité des applications. Le DAST reste essentiel : il teste les applications de l’extérieur, sonde la surface d’attaque à grande échelle à l’aide de charges utiles, comme le ferait un attaquant. L’IA ajoute une couche d’intelligence contextuelle à cette méthodologie de test et permet de détecter des vulnérabilités invisibles aux approches fondées sur la recherche de correspondances. Résultat : les vulnérabilités BOLA sont détectées avec des taux de faux positifs nettement inférieurs. Les équipes AppSec reçoivent ainsi des résultats exploitables sur lesquels elles peuvent agir immédiatement, au lieu de devoir trier le bruit.

Et BOLA n’est qu’un début. La même approche basée sur l’IA est étendue à d’autres failles d’autorisation et d’authentification du Top 10 des risques de sécurité des API de l’OWASP, car comprendre le contexte de la logique métier constitue un défi technique commun à l’ensemble des vulnérabilités liées aux contrôles d’accès. La détection des vulnérabilités BOLA pose les bases d’une approche fondamentalement plus intelligente des tests de sécurité des API.

Les questions que les responsables de la sécurité devraient se poser

Si vous êtes responsable du programme de sécurité des applications de votre organisation, les vulnérabilités BOLA devraient figurer en tête de votre évaluation des risques. Posez-vous les questions suivantes :

Savez-vous comment l’autorisation est mise en œuvre sur vos différents points de terminaison d’API, et cette mise en œuvre est-elle cohérente ? Les incohérences favorisent les vulnérabilités BOLA. Un cadre d’autorisation centralisé, appliqué à l’ensemble des services, constitue la défense architecturale la plus efficace.

Vos outils de test actuels sont-ils réellement capables de détecter les vulnérabilités BOLA, ou prétendent-ils le faire tout en générant surtout des faux positifs ? Toutes les méthodes de détection des vulnérabilités BOLA ne se valent pas. Demandez des preuves de leur précision : taux de faux positifs, méthode de détection et résultats en conditions réelles.

Comment prenez-vous en compte les conséquences de l’utilisation de code généré par l’IA sur l’autorisation ? Si vos développeurs utilisent des assistants de programmation IA, le code livré peut fonctionner correctement tout en présentant des lacunes en matière d’autorisation. Votre méthode de test doit détecter ce qui peut échapper à la revue de code.

Enfin, testez-vous vos applications de l’extérieur ? Par nature, les failles d’autorisation comme BOLA ne sont pleinement visibles que lorsque vous testez l’application comme le ferait un attaquant : en sondant des API et des applications web en cours d’exécution à l’aide de requêtes et de charges utiles réelles, avec le point de vue de quelqu’un qui cherche à accéder à ce qui devrait lui être interdit. L’analyse statique peut repérer des problèmes potentiels dans le code. Les tests dynamiques permettent de vérifier s’ils sont réellement exploitables.

Si BOLA figure au premier rang du Top 10 des risques de sécurité des API de l’OWASP, ce n’est pas un hasard. La vulnérabilité est répandue, difficile à détecter et, lorsqu’elle est exploitée, ses conséquences se chiffrent en millions de dollars et en millions d’enregistrements compromis. La bonne nouvelle, c’est que le problème de détection n’est plus insoluble : les approches basées sur l’IA permettent de repérer ces failles avec la précision et la compréhension contextuelle que les outils traditionnels n’ont jamais pu offrir. La question est de savoir si votre organisation les détectera avant qu’un attaquant ne le fasse.