Les points cl\u00e9s en bref<\/p>\n
- \n
- La surface d’attaque a chang\u00e9 de place.<\/strong> Au lieu d’une seule page web, il y a maintenant des dizaines d’interfaces derri\u00e8re les applications, les int\u00e9grations et les connexions partenaires, chacune avec son propre acc\u00e8s aux donn\u00e9es.<\/li>\n
- BOLA est en t\u00eate de la liste OWASP.<\/strong> L’autorisation manquante au niveau de l’objet, l’incr\u00e9mentation de l’ID \u00e9trang\u00e8re suffit. Cela fait partie des erreurs API les plus courantes et se trouve rarement dans le code \u00e9crit intentionnellement.<\/li>\n
- On ne prot\u00e8ge que ce que l’on conna\u00eet.<\/strong> Les API fant\u00f4mes et zombies des anciennes versions sont le probl\u00e8me silencieux. Un inventaire API est l’\u00e9tape 1, pas l’\u00e9tape 5.<\/li>\n
- Les contre-mesures sont peu spectaculaires.<\/strong> Autorisation par objet, limitation de taux, validation de sch\u00e9ma \u00e0 la passerelle. Cela fonctionne via la configuration et la discipline, pas via un appareil co\u00fbteux.<\/li>\n<\/ul>\n<\/div>\n
Related:<\/span>Kernel partag\u00e9 comme faille : comment les containers s’\u00e9chappent<\/a> \/<\/span> 14 paquets npm malveillants en 4 heures : la statique ne suffit plus<\/a><\/p>\n
Pourquoi la surface d’attaque s’est d\u00e9plac\u00e9e derri\u00e8re l’application<\/h2>\n
Il y a dix ans, la page web \u00e9tait la porte d’entr\u00e9e. Aujourd’hui, la page web n’est plus que la fa\u00e7ade, derri\u00e8re laquelle travaillent les interfaces. L’application mobile parle avec une API, le portail partenaire tire des donn\u00e9es via une API, l’ERP synchronise via une API, et l’assistant IA que quelqu’un vient d’installer appelle \u00e9galement une API. Chacune de ces connexions est une porte par laquelle les donn\u00e9es entrent et sortent.<\/p>\n
\n![\"Vue](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/06\/st-inline-260608-hero.jpg\")
Les API sont souvent cr\u00e9\u00e9es rapidement dans le code pour servir une application. La v\u00e9rification de s\u00e9curit\u00e9 est alors volontiers report\u00e9e \u00e0 plus tard. Photo : Godfrey Atima \/ Pexels<\/figcaption><\/figure>\n Le probl\u00e8me est que ces portes sont moins visibles que la page d’entr\u00e9e. Un test de p\u00e9n\u00e9tration tapote sur l’application web, un point de terminaison API utilis\u00e9 uniquement par une application passe facilement \u00e0 travers les mailles du filet. C’est pr\u00e9cis\u00e9ment ici que je ne me fie pas \u00e0 mon sentiment d’avoir tout sous contr\u00f4le. J’ai trouv\u00e9 plus souvent que je ne le souhaiterais une API dont l’\u00e9quipe jurait qu’elle n’existait plus.<\/p>\n
BOLA et la liste OWASP\u202f: o\u00f9 \u00e7a se casse concr\u00e8tement<\/h2>\n
Qu\u2019est\u2011ce que la s\u00e9curit\u00e9 des API\u202f?<\/strong> La s\u00e9curit\u00e9 des API regroupe les mesures qui prot\u00e8gent une interface de programmation contre les abus\u202f: authentification correcte, autorisation au niveau des objets et des fonctions, limitation de la charge et validation des donn\u00e9es transmises. Elle se diff\u00e9rencie de la s\u00e9curit\u00e9 web classique, car avec une API chaque appel touche directement la logique m\u00e9tier, sans couche de protection en amont.<\/p>\n
L\u2019OWASP API Security Top\u202f10 constitue la carte la plus utile des vuln\u00e9rabilit\u00e9s qui apparaissent r\u00e9ellement en pratique. En t\u00eate se trouve BOLA, Broken Object Level Authorization. Le serveur v\u00e9rifie si quelqu\u2019un est connect\u00e9, mais pas si l\u2019objet demand\u00e9 lui appartient. Un appel \u00e0 \/api\/orders\/1043<\/span> renvoie votre propre commande, celui \u00e0 \/api\/orders\/1044<\/span> renvoie celle d\u2019un tiers. Aucun outil n\u2019est n\u00e9cessaire, un simple compteur suffit.<\/p>\n
Juste \u00e0 c\u00f4t\u00e9 se trouvent l\u2019authentification d\u00e9faillante, o\u00f9 les jetons vivent trop longtemps ou sont trop laxement v\u00e9rifi\u00e9s, et la consommation illimit\u00e9e de ressources, o\u00f9 un seul client avec des requ\u00eates incessantes met l\u2019interface \u00e0 genoux. Aucune de ces failles n\u2019est exotique. Elles r\u00e9sultent du fait qu\u2019une API a \u00e9t\u00e9 construite rapidement pour servir une application, et les questions de s\u00e9curit\u00e9 ont \u00e9t\u00e9 report\u00e9es \u00e0 plus tard. Ce \u00ab\u202fplus tard\u202f\u00bb se r\u00e9alise rarement en pratique.<\/p>\n
\n\n\n
\n \nVue p\u00e9rim\u00e9trique classique<\/th>\n R\u00e9alit\u00e9 API<\/th>\n<\/tr>\n<\/thead>\n \n Prot\u00e8ge l\u2019application web visible<\/td>\n Des dizaines de points d\u2019acc\u00e8s, dont beaucoup ne sont document\u00e9s nulle part<\/td>\n<\/tr>\n \n Attaque via les champs de saisie et les sessions<\/td>\n Attaque via des IDs incr\u00e9ment\u00e9es, des faiblesses de jetons et la charge<\/td>\n<\/tr>\n \n Un WAF couvre beaucoup<\/td>\n L\u2019autorisation doit \u00eatre g\u00e9r\u00e9e par objet dans l\u2019application<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n Shadow\u2011APIs\u202f: on ne prot\u00e8ge que ce que l\u2019on conna\u00eet<\/h2>\n
Le plus gros probl\u00e8me n\u2019est g\u00e9n\u00e9ralement pas l\u2019interface dont tout le monde parle, mais celle dont personne ne se souvient. Les Shadow\u2011APIs apparaissent lorsqu\u2019une \u00e9quipe cr\u00e9e rapidement un point d\u2019acc\u00e8s et ne l\u2019int\u00e8gre jamais \u00e0 la documentation officielle. Les Zombie\u2011APIs sont d\u2019anciennes versions qui restent actives apr\u00e8s un d\u00e9ploiement, parce qu\u2019elles ne nuisent \u00e0 personne. Les deux sont non corrig\u00e9es, non v\u00e9rifi\u00e9es et souvent d\u00e9pourvues de r\u00e8gles d\u2019acc\u00e8s \u00e0 jour.<\/p>\n
C\u2019est pourquoi la s\u00e9curit\u00e9 des API ne commence pas par un outil, mais par une liste. Qui ne conna\u00eet pas ses points d\u2019acc\u00e8s ne peut pas les s\u00e9curiser, les surveiller ni les d\u00e9sactiver. Cela para\u00eet \u00e9vident, mais c\u2019est l\u2019\u00e9tape que la plupart sautent, car elle ressemble \u00e0 du travail de fond. Sans ce travail de fond, le reste n\u2019est que de la cosm\u00e9tique.<\/p>\n
Cinq \u00e9tapes qui portent la majeure partie du fardeau<\/h2>\n
La bonne nouvelle pour les entreprises de taille moyenne : la s\u00e9curit\u00e9 des API ne n\u00e9cessite rarement un nouvel appareil co\u00fbteux. Elle exige de faire quelques choses de mani\u00e8re coh\u00e9rente. Ces cinq \u00e9tapes portent la plus grande partie du fardeau.<\/p>\n
- \n
- Tenir un inventaire.<\/strong> Enregistrer chaque point de terminaison, y compris les anciens et les non officiels. Un passerelle ou un simple scan permet de voir ce qui est r\u00e9ellement accessible.<\/li>\n
- V\u00e9rifier l’autorisation par objet.<\/strong> \u00c0 chaque appel, non seulement v\u00e9rifier si quelqu’un est connect\u00e9, mais \u00e9galement si l’objet demand\u00e9 lui appartient. C’est la r\u00e9ponse directe \u00e0 BOLA.<\/li>\n
- Regrouper l’authentification \u00e0 la passerelle.<\/strong> Contr\u00f4ler les jetons, les dates d’expiration et les \u00e9tendues de mani\u00e8re centralis\u00e9e, au lieu de les construire dans chaque application de mani\u00e8re nouvelle et sujette aux erreurs.<\/li>\n
- D\u00e9finir une limitation de d\u00e9bit.<\/strong> Une limite sup\u00e9rieure par client rend difficile l’essai rapide d’IDs et intercepte la surcharge caus\u00e9e par un seul appelant. La v\u00e9ritable solution \u00e0 BOLA est fournie par l’autorisation d’objet de l’\u00e9tape deux.<\/li>\n
- Valider les entr\u00e9es selon le sch\u00e9ma.<\/strong> Ce qui ne correspond pas \u00e0 la structure attendue est rejet\u00e9 avant d’atteindre la logique m\u00e9tier.<\/li>\n<\/ol>\n
Rien de tout cela n’est nouveau, et c’est pr\u00e9cis\u00e9ment le point. Les lacunes dans les API ne se cr\u00e9ent pas parce que les connaissances manquent, mais parce que l’interface a \u00e9t\u00e9 construite sous pression et que la s\u00e9curisation a \u00e9t\u00e9 retard\u00e9e. Configurer cela une fois de mani\u00e8re propre comme standard est moins cher que le premier incident o\u00f9 quelqu’un a extrait les commandes de l’ensemble de la client\u00e8le.<\/p>\n
La premi\u00e8re \u00e9tape sans \u00e9quipe de s\u00e9curit\u00e9<\/h2>\n
Si vous n’avez pas d’\u00e9quipe de s\u00e9curit\u00e9, ne commencez pas avec l’outil le plus co\u00fbteux, mais avec la question la plus g\u00eanante : Quelles interfaces avons-nous, et qui peut acc\u00e9der \u00e0 quelles donn\u00e9es via celles-ci ? La r\u00e9ponse \u00e0 cela r\u00e9v\u00e8le g\u00e9n\u00e9ralement plus que n’importe quel scanner achet\u00e9. Une passerelle API que de nombreux fournisseurs de cloud fournissent de toute fa\u00e7on regroupe l’authentification, la limitation de d\u00e9bit et la journalisation en un seul endroit et transforme des portes dispers\u00e9es en une entr\u00e9e contr\u00f4l\u00e9e.<\/p>\n
Le reste est une question d’attitude. Une interface n’est termin\u00e9e que lorsque quelqu’un a d\u00e9cid\u00e9 qui peut l’appeler et ce qui se passe si quelqu’un le fait trop souvent. Tant que cette d\u00e9cision manque, l’API n’est pas un produit, mais une fen\u00eatre ouverte que personne n’a encore trouv\u00e9e.<\/p>\n
Foire aux questions<\/h2>\n
Qu’est-ce qui distingue la s\u00e9curit\u00e9 des API de la s\u00e9curit\u00e9 Web classique ?<\/h3>\n
La s\u00e9curit\u00e9 Web classique prot\u00e8ge une surface derri\u00e8re laquelle se trouve la logique. Une API n’a pas de surface, chaque appel frappe directement la logique. C’est pourquoi un WAF ne suffit pas, le contr\u00f4le r\u00e9el, en particulier l’autorisation par objet, doit se trouver dans l’application elle-m\u00eame.<\/p>\n
Qu’est-ce que BOLA et pourquoi est-il si r\u00e9pandu ?<\/h3>\n
BOLA signifie Broken Object Level Authorization. Le serveur v\u00e9rifie si un utilisateur est connect\u00e9, mais pas si l’objet demand\u00e9 lui appartient. Qui augmente un ID dans la requ\u00eate voit des donn\u00e9es \u00e9trang\u00e8res. Il est r\u00e9pandu parce que la v\u00e9rification est facilement oubli\u00e9e lorsque une API est construite rapidement pour une application.<\/p>\n
Ai-je besoin d’un outil de s\u00e9curit\u00e9 API co\u00fbteux ?<\/h3>\n
Pas au d\u00e9but. Un inventaire API, une autorisation par objet, une passerelle pour l’authentification et la limitation de d\u00e9bit ainsi que la validation de sch\u00e9ma couvrent la plus grande partie. Des outils sp\u00e9cialis\u00e9s aident \u00e0 la mise \u00e0 l’\u00e9chelle et \u00e0 la d\u00e9tection des Shadow-API, mais ne remplacent pas les bases.<\/p>\n
Quelles sont les Shadow- et Zombie-API ?<\/h3>\n
Les Shadow-API sont des points de terminaison qui ont \u00e9t\u00e9 construits mais jamais document\u00e9s. Les Zombie-API sont de vieilles versions qui continuent \u00e0 fonctionner apr\u00e8s une version. Les deux se soustraient \u00e0 la surveillance et portent souvent des r\u00e8gles d’acc\u00e8s obsol\u00e8tes. Ils sont une raison principale pour laquelle un inventaire complet est la premi\u00e8re \u00e9tape.<\/p>\n
O\u00f9 un moyen entreprise sans \u00e9quipe de s\u00e9curit\u00e9 devrait-il commencer ?<\/h3>\n
\u00c0 l’inventaire : Quelles interfaces existent, et qui peut acc\u00e9der \u00e0 quelles donn\u00e9es via celles-ci ? Ensuite, utiliser une passerelle API que de nombreux fournisseurs de cloud fournissent pour regrouper l’authentification, la limitation de d\u00e9bit et la journalisation de mani\u00e8re centralis\u00e9e. C’est moins cher et plus efficace qu’un scanner achet\u00e9 sans bases.<\/p>\n
Conseils de lecture de la r\u00e9daction<\/h3>\n
- V\u00e9rifier l’autorisation par objet.<\/strong> \u00c0 chaque appel, non seulement v\u00e9rifier si quelqu’un est connect\u00e9, mais \u00e9galement si l’objet demand\u00e9 lui appartient. C’est la r\u00e9ponse directe \u00e0 BOLA.<\/li>\n
- BOLA est en t\u00eate de la liste OWASP.<\/strong> L’autorisation manquante au niveau de l’objet, l’incr\u00e9mentation de l’ID \u00e9trang\u00e8re suffit. Cela fait partie des erreurs API les plus courantes et se trouve rarement dans le code \u00e9crit intentionnellement.<\/li>\n