API security : 2 856 CVE d'IDOR, une seule au catalogue des failles exploitées. Pourquoi, et comment tester
vos API

Une appli mobile de banque, un écran "Mon profil". Vous ouvrez le proxy, vous regardez ce que le téléphone envoie vraiment, et vous tombez sur un appel tout bête : GET /api/users/1234. Le 1234, c'est votre identifiant. Par curiosité, vous le passez à 1233. La réponse revient : 200 OK, et dedans, le nom, l'e-mail et le solde du client d'à côté. Vous venez de lire les données de quelqu'un d'autre sans jamais forcer un mot de passe. Pas d'exploit, pas de payload alambiqué : juste un chiffre incrémenté.

Ce que vous venez de faire porte un nom en API security : le BOLA (Broken Object Level Authorization), la version API de l'IDOR. C'est la faille la plus courante et la plus rentable sur une API moderne, et elle illustre bien pourquoi les API concentrent aujourd'hui l'essentiel du risque applicatif.

Pourquoi les API concentrent le risque

Il y a dix ans, la logique métier vivait derrière des pages HTML rendues côté serveur. Pour atteindre une donnée sensible, un attaquant devait passer par l'interface, ses formulaires, ses workflows. Aujourd'hui, le front est un SPA React ou une appli mobile, et tout ce qui compte transite par une API : l'authentification, les paiements, l'export de données, la gestion des droits. L'interface n'est plus qu'une couche de peinture par-dessus des endpoints qui, eux, parlent directement à la base et à la logique métier.

Autrement dit, l'API est la surface d'attaque. Et elle a trois caractéristiques qui en font une cible de choix. D'abord, elle est directe : pas de JavaScript à contourner, pas de rendu à deviner, on parle à la logique en JSON. Ensuite, elle est documentée, souvent malgré elle : un fichier OpenAPI, un schéma GraphQL introspectable, ou simplement le trafic de l'appli mobile qui révèle chaque route. Enfin, et c'est le pire, elle est sous-testée. Beaucoup d'équipes sécurisent soigneusement le parcours visible dans le navigateur et oublient que la même donnée est accessible par un endpoint que personne n'a jamais audité.

Le résultat se lit dans les incidents. Les grosses fuites de ces dernières années (opérateurs télécoms, plateformes de mobilité, réseaux sociaux) sont très souvent des histoires d'API mal protégées, pas de serveurs piratés à coups de 0-day. L'OWASP l'a acté en maintenant un classement dédié, l'OWASP API Security Top 10, distinct du Top 10 web classique. Parce que les failles d'API ne sont pas tout à fait les mêmes, et surtout, elles ne se testent pas de la même façon.

Le vrai palmarès de l'OWASP API Top 10

La liste compte dix entrées, mais dans la vraie vie, quatre ou cinq font le gros du travail. Inutile de tout réciter : voici les vedettes, celles qu'on retrouve mission après mission.

BOLA : l'autorisation au niveau objet

C'est le numéro 1 de la liste, et c'est mérité. Le BOLA, c'est la scène du début : l'API authentifie bien qui vous êtes (vous avez un token valide), mais oublie de vérifier que l'objet demandé vous appartient. Vous êtes connecté, donc l'API vous répond ; elle ne se demande jamais si l'id 1233 est bien à vous. La faille est bête, elle est partout, et elle est dévastatrice parce qu'elle se déroule en boucle : un attaquant énumère les identifiants et aspire toute la base, un enregistrement après l'autre.

Authentification cassée (Broken Authentication)

Cette catégorie couvre tout ce qui touche à la vérification de l'identité de l'appelant : tokens JWT mal validés (signature non vérifiée, algorithme none accepté), endpoints d'auth sans limitation de débit qui laissent brute-forcer un code OTP à six chiffres, refresh tokens qui n'expirent jamais, réinitialisation de mot de passe bancale. Une API dont l'authentification fuit, c'est la porte d'entrée qui rend tout le reste possible.

BOPLA : les propriétés qu'on ne devrait pas toucher

Le petit frère du BOLA, fusion de deux anciennes catégories (mass assignment et exposition excessive de données), rebaptisé BOPLA (Broken Object Property Level Authorization). Deux faces d'un même problème. Côté lecture, l'API renvoie l'objet entier là où le front n'affiche que trois champs : le JSON contient isAdmin, internalNotes ou le hash du mot de passe, et il suffit de regarder la réponse brute. Côté écriture, l'API accepte des champs qu'elle ne devrait pas : vous envoyez unPATCH de votre profil avec un"role": "admin" glissé dans le corps, et le back le mappe naïvement sur l'objet en base.

Exposition excessive de données et absence de rate limiting

Ces deux-là marchent souvent ensemble. Une API qui renvoie trop de champs (l'over-fetching côté serveur) combinée à une API sans plafond de requêtes, c'est le combo parfait pour l'exfiltration de masse. Sans rate limiting, rien n'empêche un script de taper/api/users/1 à/api/users/500000 en quelques minutes. La limitation de débit, au-delà des coûts d'infra, est un contrôle de sécurité qui transforme une fuite catastrophique en simple tentative bruyante et détectable.

2 856 CVE d'IDOR, une seule au catalogue des failles exploitées

Si le BOLA est la faille d'API la plus rentable, on s'attendrait à le voir partout dans les statistiques d'exploitation. Nous avons vérifié, sur deux bases publiques : la NVD, qui recense les CVE, et le catalogue CISA KEV, qui ne retient que les failles dont l'exploitation est confirmée. Sur les CVE publiées depuis 2015 et dotées d'une CWE, 2 856 sont classées CWE-639, l'identifiant de l'IDOR et du BOLA. Une seule figure au KEV.

Ce n'est pas que le BOLA soit rare ou anodin. C'est que le KEV recense des produits, du logiciel vendu et déployé à des milliers d'exemplaires, pour lesquels une mesure corrective existe. L'API métier de votre application mobile n'a pas de CVE, et son BOLA n'en aura jamais : s'il est exploité, il sera corrigé sans numéro public. Les statistiques publiques de failles exploitées sont structurellement aveugles à cette classe de failles, et c'est une raison de plus de la chercher soi-même.

Ce que le KEV montre bien, en revanche, c'est l'authentification cassée dans les produits. Une fonction critique accessible sans authentification (CWE-306) pèse 3,6 % des failles exploitées contre 1,17 % des CVE, soit 3,09 fois plus, et une authentification contournable (CWE-287) 2,33 fois plus. Quand une API d'administration d'un équipement ou d'un logiciel répandu oublie de vérifier qui l'appelle, l'exploitation suit. L'authentification cassée est d'ailleurs la deuxième entrée de l'OWASP API Top 10.

Côté NVD, le contrôle d'accès gagne du terrain : de 2,79 % des CVE dotées d'une CWE en 2015 à 10,05 % en 2025, avec une année 2016 atypique. Une partie de cette hausse tient à la façon dont les déclarants classent leurs CVE, et ces données ne permettent pas de dire quelle part revient à une vraie progression des défauts d'autorisation dans le code. La tendance mérite d'être notée, pas surinterprétée.

Les chiffres viennent de sources ouvertes : un miroir public des flux de la NVD (instantané au 5 octobre 2026, CVE rejetées exclues) et le catalogue KEV dans sa version 2026.10.04. Pour chaque CVE, nous retenons la CWE attribuée par la NVD, et à défaut celle de l'autorité qui l'a déclarée ; les identifiants sont comptés au sens strict. Le calcul a été rejoué depuis les fichiers bruts par une contre-expertise menée séparément, avec son propre code, qui retrouve les mêmes comptages.

REST et GraphQL : deux surfaces, deux réflexes

Les failles de fond sont les mêmes, mais chaque style d'API a ses portes d'entrée à lui.

Sur une API REST, l'attaquant raisonne en ressources et en verbes. Chaque /users/{id}, /orders/{id} est un candidat au BOLA. On teste aussi les verbes oubliés (un DELETE ou un PUT laissé accessible là où le front n'utilise que GET) et les versions d'API qui traînent, la vieille /v1/ restée en ligne sans les correctifs de la /v2/.

Sur une API GraphQL, la surface change de nature. Un seul endpoint, mais une puissance de requête énorme. Premier réflexe : tester l'introspection. Si elle est activée en production, le schéma complet se déballe d'une seule requête, chaque type, chaque champ, chaque mutation, y compris ceux que le front n'utilise pas. C'est une carte du trésor livrée à l'attaquant. Second réflexe : les requêtes imbriquées. GraphQL laisse demander un objet, puis ses relations, puis les relations de ses relations, en profondeur. Sans limite de profondeur ni de complexité, une requête récursive bien tournée fait exploser le serveur (déni de service) ou remonte des données qu'aucune vue ne montrait. Et le BOLA existe aussi en GraphQL, simplement il se cache dans un argumentid au fond d'une mutation plutôt que dans une URL.

Comment on teste une API pour de vrai

Tester une API va bien au-delà de lancer un scanner sur une URL et de lire le PDF. C'est une démarche en quatre temps, où le cerveau fait le plus gros du travail.

1. Cartographier et s'authentifier. On commence par lister les endpoints : fichier OpenAPI/Swagger s'il existe, schéma GraphQL par introspection, ou capture du trafic réel de l'appli mobile ou du SPA au proxy (Burp, mitmproxy). Puis on obtient au moins deux comptes de rôles différents, et idéalement deux comptes du même rôle. Cette dernière paire est capitale, c'est elle qui va révéler les BOLA.

2. Chasser l'IDOR/BOLA. Pour chaque endpoint qui manipule un objet par identifiant, on rejoue la requête du compte A en y glissant l'identifiant d'un objet du compte B. Si la réponse revient avec les données de B, c'est plié. On automatise ensuite l'énumération pour mesurer l'ampleur, mais la découverte, elle, est manuelle : il faut comprendre quel identifiant appartient à qui.

3. Fuzzer et malmener les entrées. On envoie à l'API ce qu'elle n'attend pas : types inversés (un tableau là où elle veut une chaîne), champs en trop pour débusquer le mass assignment, valeurs limites, caractères d'injection. On observe les codes d'erreur, les fuites de stack trace, les comportements incohérents.

4. Abuser la logique métier. La partie la plus créative. Peut-on appeler l'étape 3 d'un workflow de paiement sans avoir fait l'étape 2 ? Appliquer deux fois un code promo ? Passer une commande avec une quantité négative pour se faire créditer ? Aucun outil ne trouve ça, parce qu'aucun outil ne sait ce que votre application est censée faire.

Concrètement, sur le fil, un BOLA ressemble à ceci. Deux requêtes quasi identiques, le même en-tête Authorization, un seul chiffre qui change, et une réponse qui n'aurait jamais dû sortir :

# Requête légitime : le compte A lit son propre profil
GET /api/users/1234 HTTP/1.1
Host: api.cible.example
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...(token du compte A)

HTTP/1.1 200 OK
Content-Type: application/json

{"id":1234,"name":"Alice Martin","email":"[email protected]","balance":210.50}

# Même token, on décrémente juste l'id -> objet du compte B
GET /api/users/1233 HTTP/1.1
Host: api.cible.example
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...(toujours le token de A)

HTTP/1.1 200 OK
Content-Type: application/json

{"id":1233,"name":"Bob Durand","email":"[email protected]","balance":4820.00}
#         ^ données d'un autre client, renvoyées à un token qui n'y a aucun droit

Pourquoi un scanner ne suffit pas

Ces failles d'API qui font mal sont des failles d'autorisation métier. Or un scanner ne sait pas ce qu'est un droit dans votre application. Il peut envoyer /api/users/1233 et recevoir un200 OK : pour lui, une requête a réussi, rien d'anormal. Il n'a aucun moyen de savoir que ce 200 contient les données d'un client qui n'est pas le vôtre, parce qu'il ignore à qui appartient l'objet 1233. Cette information n'existe nulle part dans la réponse HTTP : elle est dans la logique de votre métier, dans votre tête et dans votre base.

C'est la même frontière que celle qu'on décrit pour le web classique dans l'OWASP Top 10 (le Broken Access Control y trône numéro 1, pour les mêmes raisons) : un outil attrape les injections et les composants obsolètes, mais reste aveugle sur l'autorisation, l'insecure design et l'abus de logique. Ces classes de failles ne se prouvent qu'à la main, avec deux comptes, un proxy et quelqu'un qui comprend le métier. C'est aussi la ligne de partage qu'on trace, phase par phase, dans le déroulement d'un pentest.

À retenir

• Les API concentrent le risque parce qu'elles exposent directement la logique métier et les données, qu'elles sont documentées (OpenAPI, introspection, trafic mobile) et souvent bien moins testées que l'interface visible.
• Le vrai palmarès de l'API security : BOLA (autorisation au niveau objet), authentification cassée, BOPLA (propriétés et mass assignment), exposition excessive de données et absence de rate limiting.
• Les statistiques publiques ne voient pas le BOLA : 2 856 CVE d'IDOR depuis 2015, une seule au catalogue KEV, parce qu'une API maison n'a pas de CVE. Ce qu'elles voient, c'est l'authentification absente ou contournable dans les produits, 2,33 à 3,09 fois plus présente dans les failles exploitées.
• REST se teste par ressource et par verbe ; GraphQL ajoute l'introspection à couper et les requêtes imbriquées à borner (profondeur, complexité).
• Un pentest API se mène en quatre temps : cartographier et s'authentifier, chasser l'IDOR/BOLA avec deux comptes, fuzzer les entrées, abuser la logique métier.
• Un scanner ne suffit pas : l'autorisation métier ne vit pas dans la réponse HTTP, elle ne se prouve qu'à la main.

Une API qui répond 200 OK à une requête qui n'aurait jamais dû aboutir, ça ne se voit pas dans un rapport de scan : ça se démontre, deux comptes en main. C'est ce qu'on fait sur nos missions de pentest web blackbox, où l'on attaque vos endpoints REST et GraphQL comme le ferait un vrai adversaire, avec la preuve d'exploitation à l'appui. Et si vous vous demandez ce que coûte un test capable d'aller débusquer ce genre de faille, on détaille tout dans le prix d'un test d'intrusion web, et le contexte de décision (pourquoi, quand, quel type) dans le pentest en entreprise.

Questions fréquentes sur la sécurité des API