En matière de défaillance du contrôle d’autorisation au niveau des objets (BOLA) — l’une des dix principales vulnérabilités de sécurité des API selon l’OWASP —, l’approche « shift left » est une stratégie incomplète. La BOLA n’est pas une simple erreur de codage, telle qu’une faute de frappe ; il s’agit d’une défaillance fondamentale de la logique métier.
Compter sur les développeurs pour vérifier manuellement chaque règle de propriété dans un vaste environnement de microservices est un pari très risqué. En 2026, compte tenu des règles strictes de la Securities and Exchange Commission (SEC) des États-Unis en matière de divulgation et de l’application rigoureuse du règlement général sur la protection des données (RGPD), un « bug de logique » peut rapidement se transformer en catastrophe financière majeure.
Anatomie de la faille d’autorisation
À l’ère des architectures monolithiques, l’autorisation était implicite. Le serveur conservait la session dans sa propre mémoire, savait exactement qui était connecté et contrôlait la requête adressée à la base de données au sein d’un processus unique et centralisé.
Les architectures cloud modernes ont fait voler ce modèle en éclats. Aujourd’hui, nous dissocions l’identité (gérée par des fournisseurs externes) des données (réparties entre des centaines de services distincts). Nous vérifions l’identité de l’utilisateur à l’entrée, mais nous laissons souvent au développeur backend le soin de vérifier ce qu’il possède ou ce à quoi il peut accéder.
“En 2026, les attaques BOLA figurent parmi les moyens les plus rapides de subir une violation de données. Le « shift left » est efficace pour détecter les bugs techniques, mais le « stay right » est le seul moyen de corriger les failles dans la logique métier.”
La « faille d’autorisation » désigne l’espace entre une connexion réussie et l’absence de vérification de la propriété. Comme les services modernes sont sans état, ils font intrinsèquement confiance aux requêtes qu’ils reçoivent. Si une requête contient « Commande 7788 » et que le code ne vérifie pas explicitement que cette commande appartient à l’auteur de la requête, les données sont volées.
Visualiser la faille d’autorisation
Pour comprendre pourquoi le recours exclusif à un pare-feu d’application web (WAF) ne suffit pas à se protéger contre les vulnérabilités BOLA, il faut examiner la déconnexion technique entre l’authentification et la propriété des ressources dans les API modernes sans état. Les WAF recherchent une syntaxe « malveillante », comme celle d’une injection SQL, tandis que les attaques BOLA utilisent une syntaxe « valide » qui ressemble à une requête normale. Pour bloquer les attaques BOLA, votre système de défense doit tenir compte de l’identité et vérifier que l’utilisateur est autorisé à accéder à l’objet précis qu’il demande.
Prenons l’exemple d’une application bancaire. Un attaquant, l’utilisateur A, se connecte à son propre compte (ID utilisateur : 8899) et reçoit un jeton de session valide. Cet utilisateur est désormais authentifié, et l’attaquant peut tenter d’accéder aux données d’un autre utilisateur, l’utilisateur B, en envoyant une requête à /api/v1/accounts/1234/balance.
Le WAF vérifie l’absence d’injections SQL ou de scripts malveillants. Comme 1234 est un entier parfaitement valide et que la syntaxe est correcte, le WAF laisse passer la requête.
La passerelle API vérifie que le jeton de session est valide et qu’il n’a pas expiré. Comme l’utilisateur A, l’attaquant, est un utilisateur légitime et connecté, la passerelle considère la requête comme authentifiée et la transmet aux systèmes internes du backend.
Par conséquent, le service backend reçoit la requête « de confiance » et renvoie le solde du compte 1234. L’attaquant a réussi à contourner la sécurité, car la passerelle a confirmé qui il était, mais n’a jamais vérifié à quoi il était autorisé à accéder.
Dans de nombreuses architectures modernes, la passerelle API joue le rôle d’un « videur » qui se contente de vérifier les pièces d’identité à l’entrée. Dès qu’un utilisateur fournit un JWT ou un cookie de session valide, la passerelle considère que toutes les requêtes ultérieures de cet utilisateur sont légitimes.
L’utilisateur A se connecte et reçoit un jeton valide. Il envoie ensuite une requête à GET/api/v1/data/1234. L’étape suivante du processus consiste à vérifier la syntaxe et la session : le WAF standard confirme que la requête est sûre (aucune injection SQL) et la passerelle API confirme que la session est valide.
C’est ici que se situe la faille d’authentification : ni le WAF ni la passerelle ne vérifient si la ressource 1234 appartient réellement à l’utilisateur A. Le service backend fait aveuglément confiance à la requête « vérifiée » par la passerelle et transmet à l’utilisateur A les données privées de l’utilisateur B. C’est à ce stade que la violation de données se produit.
Cependant, avec une solution avancée de sécurité des API, ce nouveau vigile ne se contente pas de vérifier l’identité de l’utilisateur à l’entrée ; il s’assure que celui-ci est autorisé à accéder à chaque pièce dans laquelle il tente d’entrer.
Voici les étapes suivies par les solutions avancées de sécurité des API pour combler les lacunes en matière d’authentification et vérifier que l’utilisateur connecté est autorisé à effectuer l’action demandée sur l’objet concerné.
Lors de la première étape, le système extrait l’identité (Utilisateur A) du jeton et l’identifiant de la ressource (1234) de la requête. Ensuite, à l’aide d’une cartographie de la logique métier apprise, la plateforme détermine que la ressource 1234 appartient à l’Utilisateur B, et non à l’Utilisateur A.
Lors de la troisième étape, comme la correspondance entre l’identité et la ressource échoue au contrôle logique, la requête est bloquée à la périphérie de l’application, avant de pouvoir interagir avec les systèmes internes. Au final, la requête non autorisée n’atteint jamais le backend de l’application, où les données sont stockées, ce qui empêche toute exfiltration de données avant même qu’elle ne commence.
Pourquoi l’approche « shift left » ne parvient pas à empêcher les attaques BOLA
Le fait d’avancer les contrôles et les tests de sécurité aux premières étapes du cycle de développement ne suffit pas à résoudre ce problème, car les stratégies « shift left » manquent de contexte. Les outils tels que l’analyse statique (SAST) examinent le code, et non les données. Ils ne peuvent donc pas savoir que l’utilisateur A n’est pas autorisé à consulter la facture de l’utilisateur B, puisque cette relation est définie dans la base de données et non dans le code source.
En outre, la plupart des outils d’analyse dynamique (DAST) effectuent leurs analyses uniquement dans le contexte d’un seul utilisateur. Ils voient une réponse « 200 OK » et considèrent le test comme réussi, sans savoir que l’utilisateur accède aux données privées d’un autre utilisateur.
À l’inverse, les tests d’API standards ne tiennent pas compte du contexte. En substance, c’est comme effectuer des tests dans le vide. Cette approche échoue parce qu’elle ignore les données de trafic réelles. Si vos tests ne peuvent pas voir comment l’Identité A est associée à la Ressource B en production, ils ne peuvent valider que la syntaxe, et non la logique. Vous ne testez pas votre activité.
Application des règles en périphérie
Pour résoudre ce problème, les organisations doivent adopter une stratégie d’exécution à trois niveaux, composée des éléments suivants :
- Mappage utilisateur-ressource. La solution de sécurité des API extrait l’identité du jeton et la compare à l’identifiant de la ressource dans le message de requête HTTP (en-tête, cookie, chemin ou corps).
- Un side-car Open Policy Agent (OPA). Au lieu de faire confiance à des centaines de développeurs pour écrire chacun leurs propres contrôles, utilisez OPA pour gérer les règles d’autorisation de manière centralisée. Un side-car OPA est un modèle de déploiement qui s’exécute parallèlement à un conteneur d’application afin de fournir des décisions d’autorisation locales rapides et performantes, permettant ainsi d’évaluer les politiques en temps réel pour les microservices et la sécurité des API.
- Surveillance comportementale. Pour stopper les attaques BOLA, votre système de défense doit extraire l’identité (qui), le contexte (comment) et la ressource (quoi) du trafic en temps réel afin d’établir une base de référence des relations normales. Par exemple, si le comportement d’un utilisateur s’écarte de cette base de référence, notamment s’il tente d’accéder à 50 identifiants différents en une minute, le système détecte cette anomalie. Il s’agit clairement de la signature d’un robot d’extraction de données, et non d’un humain, qui doit être bloqué immédiatement.
Comment F5 vous aide
F5 Distributed Cloud API Security offre une voie claire pour passer d’une visibilité nulle à une protection renforcée lors de l’exécution. Intégré à F5 Distributed Cloud Services, ce service assure une sécurité unifiée en regroupant la diffusion et la sécurité des applications au sein d’une même plateforme. En corrélant les renseignements issus de différents composants, tels que la protection contre les attaques par déni de service distribué (DDoS), la lutte contre les bots, la sécurité des API et le WAF, il s’appuie sur l’automatisation pour distinguer la requête d’un client isolé des attaques coordonnées à vecteurs multiples.
La fonctionnalité de découverte des API du produit détecte automatiquement toutes les API, y compris les « API fantômes », et analyse en continu le trafic de production afin d’identifier la logique métier réelle de votre application et de cartographier la manière dont les utilisateurs interagissent avec des objets de données spécifiques. Les tests contextuels s’appuient sur ces informations pour effectuer des « tests matriciels » ciblés dans les environnements de préproduction et repérer les points faibles dans les correspondances entre identités et objets avant le déploiement du code.
Distributed Cloud API Security assure également la détection des attaques BOLA en identifiant différents scénarios BOLA grâce à la corrélation entre les modèles comportementaux de référence appris et les requêtes entrantes afin de détecter toute activité suspecte, ce qui peut contribuer à la mise en place de protections à l’exécution.
En 2026, les attaques BOLA comptent parmi les moyens les plus rapides de subir une violation de données. L’approche « shift left » est efficace pour détecter les bugs techniques, mais « rester à droite » est le seul moyen de corriger les failles de logique métier. Déplacez vos contrôles d’autorisation vers la périphérie et mettez fin dès maintenant à la fuite de données.
Découvrez comment F5 peut aider les entreprises à protéger leurs API, ou voyez la solution en action.
À propos des auteurs
Articles de blog associés
IA et cybersécurité
Découvrez comment l’IA et la cybersécurité fonctionnent de concert. Découvrez comment l’IA et le machine learning (ML) permettent à votre entreprise de rester sécurisée, efficace et prête à innover avec F5.
Suivre le rythme de l’innovation de pointe ne suffit pas à faire avancer l’entreprise : se préparer à la réglementation de l’IA
À mesure que la réglementation de l’IA évolue, réfléchissez aux mesures de protection que vous pouvez mettre en place dès maintenant.
Les contrôleurs de mise à disposition d’applications reviennent au cœur des priorités stratégiques
L’IA rebat les cartes de la livraison d’applications. Nirav Shah de F5 revient sur la nouvelle étude de Gartner® consacrée aux ADC et explique ce qu’elle implique pour les décisions des entreprises en matière d’infrastructure.
Ce que nos clients nous disent sur l’IA, le multicloud hybride et la sécurité des applications
Le nouveau vice-président senior du marketing produit de F5 explique les pressions liées à l’IA auxquelles sont confrontés les dirigeants d’entreprise et ce dont ils ont besoin pour renforcer leur organisation.
Cinq niveaux de cyberrésilience antifragile transforment les pratiques en résultats
Découvrez comment cinq niveaux de résilience antifragile transforment les perturbations en comportements adaptatifs qui limitent les défaillances et renforcent l’architecture multicloud hybride.
Optimiser les pipelines d’IA en éliminant les goulets d’étranglement dans les charges de travail modernes
À mesure que les charges de travail d’IA montent en puissance, les entreprises constatent des ralentissements provenant du pipeline de données en amont qui alimente le modèle d’IA. Voici comment F5 BIG-IP peut les aider.