OWASP API Security Top 10 2023 : l’autorisation à trois granularités

Le Top 10 OWASP des risques de sécurité des interfaces de programmation est la deuxième édition de ce référentiel, publiée en 2023, quatre ans exactement après la première. Son intérêt ne tient pas à ce qu’il répète du Top 10 web — mauvaise configuration, falsification de requête côté serveur, authentification — mais à ce qu’il découpe autrement. Trois de ses dix entrées portent sur l’autorisation, à trois granularités différentes : l’objet, la propriété de l’objet, la fonction. C’est le cœur du sujet, et c’est précisément ce que le Top 10 web range sous une seule catégorie.

→ Lire l’explication complète de la marmotte

Les dix entrées de l’édition 2023

Code	Titre officiel	Traduction
API1:2023	Broken Object Level Authorization	Autorisation défaillante au niveau de l’objet
API2:2023	Broken Authentication	Authentification défaillante
API3:2023	Broken Object Property Level Authorization	Autorisation défaillante au niveau de la propriété d’objet
API4:2023	Unrestricted Resource Consumption	Consommation de ressources non restreinte
API5:2023	Broken Function Level Authorization	Autorisation défaillante au niveau de la fonction
API6:2023	Unrestricted Access to Sensitive Business Flows	Accès non restreint aux flux métier sensibles
API7:2023	Server Side Request Forgery	Falsification de requête côté serveur
API8:2023	Security Misconfiguration	Mauvaise configuration de sécurité
API9:2023	Improper Inventory Management	Gestion d’inventaire défaillante
API10:2023	Unsafe Consumption of APIs	Consommation non sécurisée d’API tierces

Trois entrées pour une seule question : qui a le droit, sur quoi, exactement

C’est l’angle à retenir, parce qu’aucun autre référentiel ne le pose aussi nettement.

API1, l’autorisation au niveau de l’objet. Une interface de programmation expose des points d’entrée qui manipulent des identifiants d’objets. Toute fonction qui atteint une source de données à partir d’un identifiant fourni par le client doit vérifier que ce client a le droit d’atteindre cet objet. La surface est immense et le test est trivial : incrémenter un entier. C’est la faiblesse la plus répandue des interfaces de programmation et le site lui consacre une page entière, parce qu’un contrôle de rôle correct ne la bloque jamais — l’attaquant a le bon rôle, il n’a simplement pas le bon objet.

API3, l’autorisation au niveau de la propriété. Cette catégorie fusionne deux entrées de 2019 : « Excessive Data Exposure » et « Mass Assignment ». Les auteurs ont fait le même mouvement que le Top 10 web, du symptôme vers la cause : les deux anciennes entrées décrivaient un objet qui révèle trop de champs en lecture et un objet qui accepte trop de champs en écriture ; la cause unique est l’absence de contrôle d’autorisation au niveau du champ. Un service qui renvoie l’objet complet et laisse l’interface décider quoi afficher expose tout à qui lit la réponse brute. Un service qui lie la totalité du corps de requête à son modèle de données accepte role: admin en bonus. Dans les deux cas l’autorisation sur l’objet est correcte : c’est la granularité qui est fausse.

API5, l’autorisation au niveau de la fonction. Ici, l’objet est le bon et le champ est le bon, mais l’opération ne devrait pas être disponible pour ce rôle. Les politiques d’accès complexes, avec des hiérarchies, des groupes et une frontière floue entre fonctions d’administration et fonctions ordinaires, produisent mécaniquement ce défaut. Le test consiste à appeler la même route avec un verbe différent, ou une route d’administration avec un jeton d’utilisateur ordinaire.

Les trois se cumulent, et c’est tout l’intérêt du découpage : une interface peut être parfaitement correcte sur l’une et ouverte sur les deux autres. Un contrôle d’autorisation unique, posé à l’entrée et validant « ce client est authentifié et a le rôle client », satisfait zéro de ces trois exigences. La conception d’interface pensée d’abord pour le contrat aide, parce qu’elle force à écrire ce qui est exposé avant de l’exposer.

Trois nouveautés de 2023 qui ne sont pas des défauts de code

API6, l’accès non restreint aux flux métier sensibles, est l’entrée la plus inhabituelle du référentiel, et les auteurs le disent explicitement : cela ne vient pas nécessairement d’un défaut d’implémentation. Le risque est qu’un flux métier légitime — acheter un billet, poster un commentaire, créer un compte, réserver un créneau — soit exposé sans compensation pour ce qui arrive s’il est exécuté de façon massive et automatisée. Aucune requête n’est malformée, aucune autorisation n’est contournée, et pourtant le modèle économique se vide. La contre-mesure n’est pas un correctif mais une analyse : identifier les flux dont l’abus automatisé nuit à l’activité, puis leur poser une friction proportionnée. C’est le genre de risque que la plupart des outils de test ne verront jamais, puisque le système fonctionne exactement comme prévu.

API4, la consommation de ressources non restreinte, remplace l’ancienne entrée « Lack of Resources & Rate Limiting ». Le déplacement d’accent est utile : il ne s’agit plus de la vitesse à laquelle on épuise une ressource, mais de la ressource elle-même. Bande passante, processeur, mémoire, stockage, et surtout les ressources facturées à la requête : envois de courriels et de messages, appels téléphoniques, validations biométriques, et aujourd’hui inférences de modèles. Une attaque réussie ne produit pas forcément une indisponibilité : elle produit une facture. Le site traite ce basculement pour l’intelligence artificielle dans le déni de portefeuille sur une API d’IA.

API10, la consommation non sécurisée d’API tierces, renverse la perspective. Toutes les autres entrées décrivent une interface qu’on expose ; celle-ci décrit une interface qu’on appelle. Le constat des auteurs est net : les développeurs font davantage confiance à une donnée reçue d’un service tiers qu’à une saisie utilisateur, et appliquent donc des contrôles plus faibles — pas de validation de schéma, pas de limite de taille, redirections suivies sans examen, transport parfois non chiffré. L’attaquant en tire une conclusion rationnelle : plutôt que d’attaquer la cible, compromettre un service qu’elle intègre. Une réponse de partenaire est une entrée non fiable comme une autre.

API9 : on ne protège pas ce qu’on n’a pas inventorié

La gestion d’inventaire défaillante n’a pas le prestige d’une faille d’autorisation, et c’est pourtant l’entrée qui conditionne les autres. Une interface de programmation expose bien plus de points d’entrée qu’une application web classique, et ils se multiplient par version. L’ancienne version v1, laissée en service « le temps que les clients migrent », n’a pas reçu les correctifs de la v2. L’environnement de recette, accessible depuis Internet parce que c’était plus simple, pointe sur une copie récente de la base. Le point d’entrée de diagnostic, activé pour une investigation en 2023, répond encore.

Les auteurs demandent donc trois inventaires distincts : les hôtes, les versions déployées par environnement, et les intégrations tierces — avec, pour chacune, les données échangées et la politique de sécurité du partenaire. Une documentation à jour n’est pas une coquetterie d’équipe : c’est la condition pour que les neuf autres entrées aient un périmètre.

Ce que la méthode de cette édition ne prétend pas être

Un détail des notes de version mérite d’être su de quiconque cite ce document. Pour cette deuxième édition, le projet a lancé — pour la première fois — un appel public à données. Personne n’a contribué. Les auteurs l’écrivent sans détour et expliquent qu’ils ont construit la liste sur l’expérience de l’équipe, une relecture par des spécialistes de la sécurité des interfaces de programmation et les retours de la communauté sur la version candidate. La prévalence annoncée pour chaque entrée résulte d’un consensus entre membres de l’équipe, pas d’une mesure.

Ce n’est pas un défaut, c’est une information. Le document est honnête, et il reste la meilleure taxonomie disponible sur le sujet ; simplement, il n’a pas le statut du Top 10 web, qui s’appuie sur des millions d’applications testées. Un appel à données auquel aucune organisation ne répond est d’ailleurs un résultat en soi : il suggère que très peu d’équipes disposent de mesures exploitables sur leurs propres interfaces, ce qui est cohérent avec l’existence d’API9 dans la liste.

Le référentiel se présente lui-même comme un document de sensibilisation tourné vers l’avant, pour un secteur qui bouge vite, et précise qu’il ne remplace aucun autre Top 10. La façon de citer ces documents selon leur niveau de maturité est traitée dans la page chapeau des Top 10 de l’OWASP.

Ce que le Top 10 web ne dit pas de la même façon

Quatre entrées se recouvrent franchement avec le référentiel web : l’authentification (API2), la falsification de requête côté serveur (API7, fondue dans A01 depuis 2025), la mauvaise configuration (API8) et, partiellement, la consommation de ressources. Les six autres sont propres à l’objet.

La différence de fond est la nature du client. Une application web a une interface : on peut y cacher un bouton, y imposer un enchaînement d’écrans, y mettre un jeton anti-rejeu. Une interface de programmation n’a pas d’interface, au sens où le client est un programme qui appelle ce qu’il veut dans l’ordre qu’il veut. Toute hypothèse de séquence est fausse, toute vérification côté client est décorative, et chaque point d’entrée doit se défendre seul. Une passerelle d’API peut porter l’authentification, la limitation de débit et l’inventaire ; elle ne peut pas porter l’autorisation sur l’objet, parce qu’elle ne sait pas à qui appartient la facture 4127. Cette décision-là reste dans le service, à chaque appel.

🐝 Ce qui arrive si on s’en passe

Sans distinguer les trois granularités d’autorisation, un contrôle unique posé à l’entrée laisse passer les deux autres : le rôle est vérifié, la propriété de l’objet ne l’est pas, et un client lit les factures d’un autre en changeant un entier dans l’URL. Sans contrôle au niveau du champ, une réponse renvoie l’objet complet et l’interface se contente de masquer ce qu’elle n’affiche pas : la donnée sensible part sur le réseau et se lit dans la réponse brute, tandis qu’un corps de requête lié en bloc au modèle accepte un champ de privilège que personne n’a prévu d’exposer. Sans analyse des flux métier sensibles, un parcours légitime exécuté en masse épuise un stock ou une enveloppe facturée à la requête sans qu’aucune alerte technique ne se déclenche, puisque rien ne dysfonctionne. Sans inventaire des hôtes, des versions et des intégrations, une version dépréciée reste en service sans ses correctifs et un point d’entrée de diagnostic continue de répondre, hors de tout périmètre de test.

🦫 Explication de la marmotte 🍫

Une interface de programmation permet à deux logiciels d’échanger des données sans intervention humaine : une application mobile demande le solde d’un compte, un site demande une liste de produits, un partenaire envoie une commande. Une association internationale de spécialistes publie une liste des dix problèmes de sécurité les plus courants dans ces échanges. La version actuelle date de 2023.

Trois de ces dix problèmes concernent la même question posée à trois niveaux de détail. Le premier niveau : la personne a-t-elle le droit de consulter ce dossier précis, et pas seulement des dossiers en général ? Le deuxième : a-t-elle le droit de voir, ou de modifier, cette information précise à l’intérieur du dossier ? Le troisième : a-t-elle le droit d’effectuer cette opération, par exemple supprimer plutôt que lire ? Une vérification faite à un seul de ces niveaux laisse les deux autres ouverts.

D’autres entrées de la liste ne décrivent pas des erreurs de programmation. L’une signale qu’une opération parfaitement normale, répétée automatiquement des milliers de fois, peut vider un stock ou faire exploser une facture. Une autre signale que les données reçues d’un partenaire sont souvent moins contrôlées que celles saisies par un utilisateur, ce qui incite les attaquants à s’en prendre au partenaire plutôt qu’à la cible.

Une dernière entrée est moins spectaculaire et tout aussi importante : il faut savoir quelles interfaces existent, dans quelles versions, et sur quels serveurs. Une ancienne version restée en service ne reçoit plus les corrections, et un outil de diagnostic oublié continue de répondre à qui le demande.

Pages voisines

La citent

OWASP API Security Top 10 2023 : l'autorisation à trois granularités

Elle cite

: les deux pages se citent l’une l’autre.