L'OWASP API Security Top 10 existe parce que les API se cassent d'une manière que les applications web classiques ignorent. Une application côté navigateur cache sa logique derrière des pages rendues ; une API vous livre les endpoints bruts, les identifiants d'objets et le JSON, puis vous fait confiance pour ne demander que ce qui vous appartient. C'est exactement cette confiance que les attaquants exploitent. Pour la ressentir plutôt que simplement la lire, ouvrez le cours API Security Testing de HackerDNA et suivez chaque risque ci-dessous, associé à une leçon pratique.
Cette liste est le pendant spécifique aux API du OWASP Top 10 plus général. Elle a été reconstruite dans l'édition 2023 autour des failles qui apparaissent vraiment lors des tests d'intrusion d'API : l'autorisation au niveau de l'objet, l'autorisation au niveau de la fonction et l'abus de logique métier. Ce guide parcourt les dix risques avec des exemples concrets, montre comment tester chacun d'eux et couvre les défenses qui tiennent en production.
TL;DR : L'OWASP API Security Top 10 (édition 2023) classe les dix risques d'API les plus critiques. Les trois premiers sont tous des défauts d'autorisation : Broken Object Level Authorization (BOLA), authentification défaillante et autorisation défaillante au niveau des propriétés d'objet. La BOLA à elle seule, où vous remplacez un identifiant d'objet par un autre et lisez des données qui ne sont pas les vôtres, est le bug d'API grave le plus courant. Les sept autres couvrent l'abus de ressources, l'autorisation au niveau des fonctions, les flux métier sensibles, la SSRF, la mauvaise configuration, les versions d'API oubliées et la confiance aveugle envers les API tierces. Apprenez à tester chacun, puis verrouillez-le avec des contrôles d'autorisation par objet plutôt qu'en faisant confiance au client.
Qu'est-ce que l'OWASP API Security Top 10 ?
L'OWASP API Security Top 10 est un document de sensibilisation standard qui classe les dix risques de sécurité les plus sérieux propres aux interfaces de programmation (API). Publié pour la première fois en 2019 et révisé en 2023, il est maintenu par l'OWASP API Security Project comme la contrepartie axée sur les API de la liste applicative web générale.
Il existe parce que les API présentent une surface d'attaque différente. Une page web traditionnelle couple les données et la présentation, donc une grande partie de la logique reste côté serveur, hors de portée. Une API REST ou GraphQL enlève tout cela : elle expose des endpoints structurés, des identifiants d'objets prévisibles et des objets de données complets directement au client. Résultat, les failles qui comptent le plus pour les API ne sont pas les mêmes que celles en tête de la liste web.
L'injection et le cross-site scripting dominent les tests d'applications web. Dans les tests d'API, la constante est l'autorisation défaillante : un endpoint qui vous authentifie correctement, puis ne vérifie jamais si l'enregistrement précis que vous avez demandé vous appartient réellement. Sept des dix éléments ci-dessous sont, au fond, des problèmes d'autorisation.
Les 10 risques de sécurité des API, expliqués
Voici l'OWASP API Security Top 10 complet pour l'édition 2023, chacun avec la faille qu'il décrit et un exemple concret d'exploitation. Les identifiants (API1 à API10) sont les étiquettes officielles de l'OWASP et vous les verrez cités dans les rapports de pentest et le tri des bug bounties. Voici la liste OWASP API Security Top 10 de l'édition 2023 en référence.
API1:2023 - Broken Object Level Authorization (BOLA)
Le serveur vérifie que vous êtes connecté mais pas que l'objet demandé est le vôtre. Vous appelez GET /api/orders/1024, voyez votre propre commande, puis changez l'identifiant en 1025 et lisez celle de quelqu'un d'autre. C'est la même cause racine qu'une faille IDOR, et c'est de loin la vulnérabilité d'API la plus répandue et la plus dommageable, référencée sous CWE-639. Chaque endpoint qui prend un identifiant a besoin d'un contrôle, à chaque requête, que l'utilisateur courant possède cet objet précis.
API2:2023 - Broken Authentication (authentification défaillante)
Le mécanisme qui prouve votre identité est mal implémenté. Cas courants : des endpoints de connexion sans limitation de débit qui tombent face au credential stuffing, des JWT signés avec un secret devinable ou acceptant l'algorithme none, des jetons passés dans l'URL où ils fuient dans les journaux, et des flux de réinitialisation de mot de passe qui n'invalident pas les anciens jetons. Une fois l'authentification cassée, tout contrôle d'autorisation en aval devient inutile.
API3:2023 - Broken Object Property Level Authorization
L'autorisation est vérifiée au niveau de l'objet mais pas au niveau de la propriété. Cela fusionne deux anciens risques. Dans le mass assignment, vous ajoutez "role": "admin" à une requête de mise à jour de profil et l'API l'associe directement à la base de données. Dans l'exposition excessive de données, un GET sur votre propre utilisateur renvoie l'enregistrement complet, y compris des champs comme passwordHash ou isVerified, en attendant que le client les cache. Les deux viennent d'une confiance dans la forme de la requête ou de la réponse au lieu de la filtrer côté serveur.
API4:2023 - Unrestricted Resource Consumption
Chaque requête d'API coûte du CPU, de la mémoire, de la bande passante ou de l'argent (pensez aux quotas de SMS et d'e-mails). Sans limitation de débit ni plafond de taille, un attaquant envoie ?limit=9999999, téléverse une charge énorme ou martèle un endpoint coûteux jusqu'à ce que le service tombe ou que la facture cloud explose. C'est le risque derrière le déni de service comme derrière les coûts tiers incontrôlés.
API5:2023 - Broken Function Level Authorization
Là où la BOLA concerne les données que vous pouvez toucher, ceci concerne les actions que vous pouvez effectuer. Un utilisateur standard découvre la route admin POST /api/admin/users ou remplace un GET par un DELETE, et le serveur l'exécute, parce que le contrôle de rôle vit dans l'interface et non dans l'endpoint. Les chemins admin devinables et les méthodes HTTP non protégées sont les portes d'entrée habituelles.
API6:2023 - Unrestricted Access to Sensitive Business Flows
Un flux fonctionne exactement comme prévu, mais l'API ne considère jamais ce qui arrive lorsqu'il est automatisé. Des scripts achètent tous les billets de concert dès leur sortie, créent en masse des comptes pour exploiter un bonus d'inscription, ou aspirent tout un catalogue produit. Il n'y a pas de « bug » unique à corriger ici, la parade est de détecter et limiter l'usage anormal d'une fonctionnalité légitime.
API7:2023 - Server Side Request Forgery
Une API récupère une ressource distante depuis une URL fournie par l'utilisateur sans la valider, vous pointez donc le serveur vers des cibles internes comme http://169.254.169.254 pour dérober des identifiants cloud. La SSRF a migré sur la liste des API parce que les fonctions « importer depuis une URL » et les webhooks sont partout dans les API modernes. Notre guide complet de l'attaque SSRF couvre les payloads et les contournements de filtres en profondeur.
API8:2023 - Security Misconfiguration (mauvaise configuration)
L'API fonctionne, mais le déploiement fuit. Traces de pile verbeuses dans les réponses d'erreur, en-têtes de sécurité manquants, CORS permissif renvoyant Access-Control-Allow-Origin: * sur des endpoints authentifiés, méthodes HTTP inutiles laissées actives et composants non corrigés siègent tous ici. Aucun n'est un exploit astucieux, ce sont des réglages par défaut que personne n'a durcis.
API9:2023 - Improper Inventory Management
Vous ne pouvez pas protéger un endpoint dont vous avez oublié l'existence. Une équipe livre /api/v3/, la corrige et laisse tourner l'ancienne /api/v1/ avec le bug d'origine. Ces API « zombies » et « fantômes », plus les hôtes de préproduction exposés et les endpoints de debug non documentés, sont une cible de bug bounty favorite précisément parce que personne ne les surveille.
API10:2023 - Unsafe Consumption of APIs
Les développeurs valident soigneusement les entrées utilisateur, puis font entièrement confiance aux données des API tierces. Si votre service tire d'une API partenaire et injecte la réponse dans une requête ou suit ses redirections sans contrôle, une compromission de ce partenaire devient une compromission de vous. Traitez les API intégrées comme des entrées non fiables, au même titre que tout ce qu'un utilisateur soumet.
Comment tester une API face au Top 10
Comment tester une API pour ces risques ? Commencez par cartographier chaque endpoint, puis attaquez d'abord l'autorisation : rejouez chaque requête en tant qu'utilisateur différent et avec des identifiants d'objets falsifiés. Les bugs d'autorisation (BOLA et niveau fonction) sont les découvertes de plus grande valeur et les plus faciles à manquer avec des scanners automatiques, ils méritent donc une attention manuelle.
Un ordre d'opérations pratique :
- Énumérez la surface. Récupérez la spécification Swagger ou OpenAPI, faites passer le client web ou mobile par Burp, et listez chaque route, méthode et paramètre. Notez ceux qui prennent des identifiants.
- Testez l'autorisation au niveau de l'objet. Capturez une requête pour un de vos objets, puis rejouez-la avec l'identifiant d'un autre utilisateur. Si vous récupérez ses données, c'est de la BOLA (API1).
- Testez l'autorisation au niveau de la fonction. Prenez une action réservée à l'admin capturée sur un compte privilégié et rejouez-la avec un jeton à faibles privilèges. Essayez aussi de changer la méthode HTTP.
- Sondez les propriétés. Ajoutez des champs inattendus comme
roleouisAdminaux requêtes d'écriture (mass assignment) et inspectez les réponses de lecture pour les champs que l'interface cache (exposition excessive de données). - Frappez les limites. Supprimez les limitations de débit en changeant de jeton, demandez des pages surdimensionnées, et guettez l'abus de ressources et de flux métier.
Lors de tests sur des applications réelles, la découverte qui paie le plus souvent reste la BOLA sur une route imbriquée. Les équipes protègent l'endpoint évident /users/{id}, puis oublient la sous-ressource /users/{id}/documents/{docId}, où le second identifiant n'est jamais vérifié par rapport au premier. Testez toujours l'identifiant le plus profond du chemin.
Comment sécuriser vos API
Se défendre contre l'OWASP API Security Top 10 tient à une poignée de contrôles appliqués de façon cohérente, pas à un produit que l'on greffe. Voici ceux qui font la différence :
- Autorisez chaque objet, à chaque requête. Sur chaque endpoint qui prend un identifiant, vérifiez côté serveur que l'utilisateur authentifié possède cet enregistrement précis. Cette seule habitude ferme la BOLA, le bug d'API le plus courant.
- Imposez les rôles au niveau de la fonction dans l'endpoint. Placez le contrôle de rôle dans le gestionnaire de route, jamais dans le client. Refusez par défaut, et rejetez les méthodes HTTP inattendues.
- Filtrez les propriétés à l'entrée et à la sortie. N'associez qu'une liste explicite de champs autorisés en écriture pour stopper le mass assignment, et ne sérialisez que les champs qu'un appelant doit voir en lecture.
- Limitez le débit et plafonnez tout. Fixez des quotas de requêtes, des tailles de page maximales et des limites de charge pour qu'un seul appelant ne puisse épuiser les ressources ni automatiser un flux sensible.
- Tenez un inventaire d'API. Suivez chaque hôte, version et endpoint, retirez les anciennes versions et sortez les routes de préproduction et de debug de l'internet public.
Remarquez que quatre des cinq relèvent de l'autorisation et du traitement des entrées. Réussissez-les et la majorité de la liste se ferme d'elle-même.
API Security Top 10 contre l'OWASP Top 10 original
Les deux listes se chevauchent mais ne sont pas interchangeables, et c'est là tout l'intérêt. L'OWASP Top 10 original est écrit pour des applications web complètes et mène avec de larges catégories comme l'injection et la mauvaise configuration. La liste API zoome sur les failles qui dominent les surfaces d'attaque propres aux API.
- L'autorisation est au premier plan. Trois des cinq premiers risques API sont des défauts d'autorisation (BOLA, niveau fonction, niveau propriété). Sur la liste web, ils sont regroupés en une seule entrée Broken Access Control.
- L'injection est plus discrète ici. L'injection classique compte aussi pour les API, mais elle ne mène pas comme sur le web. Quand elle apparaît, notre tutoriel d'injection SQL couvre les mécaniques qui se transposent directement aux paramètres d'API.
- La logique métier a son propre créneau. L'accès non restreint aux flux métier sensibles (API6) n'a pas d'équivalent direct sur la liste web, car l'automatisation des API en fait un problème de premier plan.
Si vous testez des applications web et des API, apprenez les deux listes. La liste web cadre les catégories de risque ; la liste API vous dit où passer réellement votre temps sur un backend JSON moderne.
Considérations légales et éthiques
Rappel essentiel : Obtenez toujours une autorisation écrite explicite avant de tester une API. Échanger des identifiants d'objets pour lire les enregistrements d'un autre utilisateur ou rejouer des requêtes admin sur un système que vous ne possédez pas constitue un accès non autorisé au titre du Computer Fraud and Abuse Act (États-Unis), du Computer Misuse Act (Royaume-Uni) et de lois équivalentes dans le monde, même quand l'API rend cela trivialement facile.
- Ne testez que des API que vous possédez, des labs d'entraînement dédiés ou des cibles dans le périmètre défini d'un engagement autorisé ou d'un programme de bug bounty.
- Les tests de BOLA exposent de vraies données utilisateur. Si vous confirmez la faille, arrêtez-vous à la preuve d'impact et ne téléchargez, ne conservez ni ne partagez jamais les enregistrements d'autrui.
- Les tests de limitation de débit et de consommation de ressources peuvent faire tomber un service. Coordonnez-vous avec le propriétaire et restez dans les limites convenues.
- Pratiquez les techniques destructrices et de logique métier sur des API volontairement vulnérables, pas sur des systèmes de production.
Questions fréquentes
Qu'est-ce que l'OWASP API Security Top 10 ?
C'est une liste de sensibilisation standard des dix risques de sécurité les plus critiques propres aux API, maintenue par l'OWASP API Security Project. L'édition 2023 actuelle mène avec des défauts d'autorisation comme la Broken Object Level Authorization (BOLA) plutôt qu'avec les failles d'injection qui dominent la liste applicative web générale.
Qu'est-ce que la BOLA et pourquoi est-elle numéro un ?
La Broken Object Level Authorization (BOLA) survient quand une API confirme que vous êtes connecté mais ne vérifie pas que l'objet précis demandé vous appartient. Changer un identifiant dans la requête renvoie les données d'un autre utilisateur. Elle est première parce qu'elle est à la fois la faille d'API la plus courante et la plus dommageable, et que les scanners automatiques la manquent régulièrement.
En quoi l'OWASP API Security Top 10 diffère-t-il de l'OWASP Top 10 ?
L'OWASP Top 10 vise les applications web complètes et mène avec de larges catégories comme l'injection. La liste API se concentre sur les surfaces d'attaque propres aux API, où les défauts d'autorisation dominent : trois de ses cinq premiers sont des bugs d'autorisation, et elle ajoute des risques comme l'abus de flux métier et la mauvaise gestion d'inventaire que la liste web ne signale pas séparément.
Comment tester mon API pour ces risques ?
Cartographiez chaque endpoint depuis la spécification OpenAPI ou un proxy, puis rejouez les requêtes en tant qu'utilisateurs différents et avec des identifiants d'objets falsifiés pour trouver les autorisations défaillantes. Sondez les champs cachés dans les réponses, les champs inattendus dans les requêtes, les limitations de débit manquantes et les anciennes versions d'API oubliées. Le test d'autorisation est un travail manuel que les scanners ne peuvent pas entièrement automatiser.
Quel est le contrôle de sécurité d'API le plus important ?
L'autorisation par objet à chaque requête. Pour chaque endpoint qui prend un identifiant d'objet, le serveur doit vérifier que l'utilisateur authentifié possède réellement cet enregistrement avant de le renvoyer. Ce seul contrôle ferme la BOLA, la vulnérabilité d'API grave la plus courante, et aucun contrôle côté client ne le remplace.
Fait partie de la série OWASP Top 10
Articles liés :
- Contrôle d'accès défaillant
- L'attaque SSRF expliquée
- Tutoriel d'injection SQL
- OWASP API Security Top 10
Vos prochaines étapes
L'OWASP API Security Top 10 prend tout son sens dès que vous exploitez le premier élément vous-même : changez un identifiant d'objet, voyez revenir les données d'un autre compte, et la BOLA cesse d'être une ligne dans une liste. Les bugs d'autorisation comme celui-ci sont invisibles pour un état d'esprit page par page et évidents dès que vous pensez en endpoints et en identifiants. Commencez avec l'offre gratuite de HackerDNA, sans carte bancaire, et cassez une vraie API dans le lab API Breaker. Quand vous voulez le parcours complet, de la reconnaissance à l'authentification, l'autorisation, le mass assignment et GraphQL, le cours API Security Testing parcourt chaque risque de cette liste en labs guidés dans le navigateur. Apprenez à tester les API comme le font les attaquants, puis allez construire les contrôles par objet qui les arrêtent.
