Pendant des années, la sécurité applicative s’est concentrée sur les pages web et les formulaires visibles dans un navigateur. Mais l’application moderne n’a plus de centre de gravité unique : c’est un assemblage de services qui dialoguent entre eux et avec l’extérieur par des interfaces de programmation, les API. Le mobile appelle des API, le site web appelle des API, les partenaires consomment des API, et les microservices ne font que cela. Cette bascule a déplacé la surface d’attaque sans que les pratiques de défense suivent au même rythme.
Cet article propose une lecture opérationnelle de la sécurité des API : pourquoi elles concentrent désormais l’essentiel des attaques applicatives, ce que dit l’OWASP API Security Top 10, les angles morts récurrents, et une démarche réaliste pour élever sa posture en 2026. La référence structurante est l’édition 2023 du Top 10 de l’OWASP [1], toujours d’actualité, complétée par le panorama des menaces de l’ENISA [3] et les retours du CERT-FR [4].
Pourquoi les API sont devenues la première cible
Une API est un contrat : elle expose des fonctions et des données à un appelant, selon des règles définies. Tant que cet appelant était un autre composant interne, sur un réseau de confiance, le risque restait contenu. La réalité de 2026 est différente. Les API sont exposées sur Internet, consommées par des applications mobiles que l’on ne maîtrise pas, ouvertes à des partenaires, et multipliées par les architectures de microservices. Chaque endpoint exposé est une porte, et chaque porte mal gardée est une opportunité pour un attaquant.
Le panorama de la menace publié par l’ENISA confirme la montée des attaques visant la couche applicative et les chaînes d’intégration, où les API jouent un rôle central [3]. Le constat tient à plusieurs raisons convergentes.
D’abord, les API exposent directement la logique métier et les données. Là où une page web présente un rendu déjà filtré, une API renvoie souvent des objets bruts, parfois plus complets que ce que l’interface affiche. Un attaquant qui interroge l’API accède à la matière première, sans la couche de présentation qui masquait les détails.
Ensuite, les API sont prévisibles. Leurs schémas suivent des conventions, leurs identifiants sont souvent séquentiels, et leur documentation, quand elle existe, décrit précisément les paramètres attendus. Cette lisibilité, précieuse pour les développeurs, l’est tout autant pour un attaquant qui cartographie ses cibles.
Enfin, la vitesse de livraison joue contre la sécurité. Les équipes déploient de nouvelles versions plusieurs fois par jour, créent des endpoints pour un besoin ponctuel, et oublient d’en retirer d’anciens. Il en résulte un parc d’API mouvant, dont une partie échappe à l’inventaire officiel. Ces API fantômes et API zombies sont rarement supervisées, donc rarement protégées.
L’OWASP API Security Top 10, le socle de référence
L’OWASP, organisation à but non lucratif de référence en sécurité applicative, publie un classement spécifique aux API. L’édition 2023 reste la version en vigueur en 2026 et structure la réflexion de la plupart des équipes de sécurité [1]. Comprendre ce classement, c’est se doter d’une grille de lecture commune entre développeurs, architectes et RSSI.
Le point le plus important à saisir est que la majorité des risques majeurs ne sont pas des failles techniques exotiques, mais des défauts de logique d’autorisation. Ce ne sont pas des injections sophistiquées : ce sont des contrôles d’accès manquants ou incomplets.
BOLA, le risque numéro un
La violation du contrôle d’accès au niveau de l’objet, désignée par l’acronyme BOLA, occupe la première place du classement [2]. Le scénario est d’une simplicité déconcertante. Une API expose un endpoint qui renvoie les données d’un objet identifié par un paramètre, par exemple le numéro d’une commande ou l’identifiant d’un dossier. L’application vérifie bien que l’appelant est authentifié, mais oublie de vérifier qu’il a le droit d’accéder à cet objet précis. Un utilisateur légitime modifie alors l’identifiant dans sa requête et consulte les données d’un autre client.
Cette faille est à la fois la plus répandue et la plus dommageable, car elle permet une fuite massive de données sans aucune compétence technique avancée. La parade tient en une règle absolue : à chaque requête, pour chaque objet demandé, le serveur doit vérifier que l’appelant authentifié est bien autorisé sur cet objet. Cette vérification ne peut jamais être déléguée au client, car le client est, par définition, sous le contrôle de l’attaquant.
Les autres défauts d’autorisation et d’authentification
Le Top 10 prolonge cette logique avec plusieurs risques apparentés. La violation du contrôle d’accès au niveau des propriétés d’objet, ou BOPLA, recouvre deux excès symétriques : exposer dans une réponse des champs sensibles que l’appelant ne devrait pas voir, ou accepter en entrée des champs qu’il ne devrait pas pouvoir modifier, comme un statut administrateur. L’autorisation au niveau de la fonction, classée séparément, vise les endpoints d’administration accessibles par défaut à des comptes ordinaires.
L’authentification défaillante figure également en bonne place. Jetons mal vérifiés, absence de limitation des tentatives de connexion, jetons à durée de vie excessive, secrets exposés dans le code mobile : autant de portes ouvertes. La gestion des identités et des accès reste un pilier transverse, que nous détaillons dans notre guide IAM et PAM 2026.
La consommation de débit et les API tierces
Deux risques complètent ce panorama. La consommation non maîtrisée de ressources concerne les API qui ne limitent ni le débit ni le volume des requêtes, et s’exposent ainsi au déni de service et à l’extraction massive de données. La consommation non sécurisée d’API tierces rappelle qu’une API consommant elle-même d’autres API hérite de leurs faiblesses, et doit traiter leurs réponses avec la même méfiance que des entrées utilisateur.
Les angles morts récurrents
Au-delà du classement, l’expérience de terrain fait ressortir trois angles morts qui reviennent dans presque toutes les organisations.
Le premier est l’inventaire incomplet. On ne protège que ce que l’on connaît, et la plupart des entités ne disposent pas d’un inventaire fiable de leurs API. Les API fantômes, créées en dehors du processus officiel, et les API zombies, anciennes versions jamais retirées, échappent à toute supervision. Elles sont d’autant plus dangereuses qu’elles ne reçoivent ni correctifs ni surveillance. Aucune démarche de sécurité des API ne tient sans un inventaire exhaustif et tenu à jour.
Le deuxième angle mort est la confiance excessive accordée à la passerelle. Une passerelle d’API gère le périmètre avec efficacité, mais elle ne voit qu’une requête autorisée en apparence. Elle ne connaît pas la règle métier qui distingue un accès légitime d’un accès frauduleux à un objet donné. Croire que la passerelle suffit revient à confondre la sécurité du périmètre avec la sécurité en profondeur, une confusion que l’approche Zero Trust vise précisément à corriger.
Le troisième angle mort est l’absence de tests adaptés. Les scanners de vulnérabilités classiques, conçus pour les applications web traditionnelles, détectent mal les failles de logique d’autorisation des API, car celles-ci dépendent du contexte métier. Un scanner ne sait pas qu’un utilisateur ne devrait pas voir la commande d’un autre. Seul un test conçu pour les API, mené par des personnes qui comprennent le métier, révèle ces failles. C’est l’un des intérêts d’un test d’intrusion ciblé.
Construire une démarche de protection
Sécuriser ses API n’est pas l’affaire d’un produit miracle, mais d’une démarche structurée qui combine plusieurs niveaux de défense. Voici les étapes qui produisent le plus d’effet, dans un ordre logique.
Étape 1 : inventorier et classer
Tout commence par la découverte. L’analyse du trafic de la passerelle, des journaux et des dépôts de code permet de recenser les API existantes, y compris celles que personne ne documentait. Chaque API est ensuite classée selon sa sensibilité : données personnelles, données financières, fonctions critiques. Cette classification oriente l’effort de protection vers ce qui compte vraiment. L’inventaire est un processus continu, pas un audit ponctuel, car de nouvelles API apparaissent à chaque déploiement.
Étape 2 : authentifier et autoriser rigoureusement
Chaque API doit exiger une authentification robuste, fondée sur des jetons à durée de vie limitée et correctement vérifiés. Surtout, chaque requête doit déclencher une vérification d’autorisation côté serveur, au niveau de chaque objet et de chaque fonction. C’est la mesure qui neutralise BOLA, le risque numéro un. La règle est de ne jamais faire confiance à un identifiant fourni par le client sans vérifier que l’appelant y a droit.
Étape 3 : valider les entrées et maîtriser les sorties
Toute donnée entrante doit être validée par rapport à un schéma strict, qui définit les champs attendus, leurs types et leurs bornes. Les champs non prévus sont rejetés, ce qui ferme la porte aux modifications de propriétés non autorisées. Symétriquement, les réponses ne renvoient que les champs nécessaires, jamais l’objet brut complet. Le guide de l’OWASP sur la sécurité des API REST détaille ces bonnes pratiques [6].
Étape 4 : limiter le débit et superviser
Chaque API impose une limitation de débit et de volume, par appelant et par endpoint, pour contenir le déni de service et l’extraction massive. La supervision centralise les journaux des API et y applique une détection d’anomalies : un appelant qui parcourt séquentiellement des milliers d’identifiants, un pic d’erreurs d’autorisation, un volume inhabituel. Cette télémétrie alimente la même chaîne de détection que le reste du système d’information, comme nous l’expliquons à propos de la journalisation et de la détection par SIEM.
Étape 5 : intégrer la sécurité au cycle de développement
La sécurité des API se gagne au plus tôt, dans la chaîne de livraison. Tests de sécurité automatisés, analyse des spécifications, vérification des dépendances et revue des contrôles d’accès s’intègrent dans la chaîne d’intégration continue. Cette approche, qui consiste à porter la sécurité en amont, relève de la démarche DevSecOps, où les correctifs coûtent infiniment moins cher qu’une fois en production.
Articulation avec la posture globale
La sécurité des API n’est pas un domaine isolé. Elle s’inscrit dans une posture de sécurité d’ensemble et s’articule avec les autres briques de défense. La gestion des vulnérabilités, que nous traitons dans notre guide CVE et CVSS, couvre les composants techniques sur lesquels reposent les API. La conformité réglementaire la rejoint également : la directive NIS2 [5] impose une sécurité du développement et une analyse des risques qui englobent nécessairement les interfaces exposées, comme le détaille notre guide NIS2 pour l’entreprise.
L’erreur stratégique serait de traiter la sécurité des API comme un projet technique ponctuel, confié à une seule équipe et clos une fois la passerelle déployée. Les API évoluent en permanence, leur surface change à chaque livraison, et les attaquants industrialisent leurs campagnes. La protection durable repose sur une discipline d’inventaire, une exigence d’autorisation systématique, et une supervision intégrée à la détection globale. Bien menée, elle transforme la principale surface d’attaque applicative en une frontière maîtrisée. Négligée, elle reste le maillon faible que les attaquants connaissent déjà mieux que les défenseurs.
Questions fréquentes
Une passerelle d’API suffit-elle à sécuriser mes API ?
Non. Une passerelle d’API gère efficacement le périmètre : authentification, limitation de débit, terminaison TLS, journalisation centralisée. Mais elle ne connaît pas la logique métier de chaque service. La majorité des risques du Top 10 OWASP, à commencer par la violation du contrôle d’accès au niveau de l’objet, se situent au cœur de l’application, là où la passerelle ne voit qu’une requête autorisée en apparence. La passerelle est nécessaire mais insuffisante : chaque microservice reste responsable de vérifier que l’appelant a le droit d’accéder à l’objet précis qu’il demande.
Quelle différence entre authentification et autorisation pour une API ?
L’authentification répond à la question « qui es-tu ? » : elle vérifie l’identité de l’appelant, généralement via un jeton. L’autorisation répond à la question « as-tu le droit ? » : elle vérifie que cet appelant peut effectuer l’action demandée sur l’objet visé. Une erreur fréquente consiste à authentifier correctement puis à oublier d’autoriser au niveau de chaque objet. Un utilisateur authentifié peut alors accéder aux données d’un autre en modifiant un identifiant dans l’URL. C’est précisément la faille BOLA, classée numéro un par l’OWASP.
Les API GraphQL sont-elles plus sûres que les API REST ?
Ni plus ni moins, mais elles déplacent les risques. GraphQL réduit certaines erreurs de surexposition de données côté serveur, puisque le client choisit les champs. En revanche, il introduit des risques propres : des requêtes imbriquées trop profondes peuvent provoquer un déni de service, et le contrôle d’accès au niveau des champs devient plus délicat. Les principes de sécurité restent les mêmes : autorisation systématique, limitation de la complexité des requêtes, validation des entrées. Le format de l’API ne dispense d’aucun contrôle.
La sécurité des API est-elle concernée par NIS2 ?
Oui, indirectement. NIS2 n’évoque pas les API nommément, mais impose une analyse des risques, une sécurité du développement et de la maintenance des systèmes, ainsi qu’une gestion des vulnérabilités. Pour une entité dont les services reposent sur des API, satisfaire ces exigences passe nécessairement par leur sécurisation. Les API exposées vers des partenaires ou le public entrent par ailleurs dans le périmètre de sécurité de la chaîne d’approvisionnement, autre point d’attention explicite de la directive.
Comment découvrir les API que je ne connais pas encore ?
Plusieurs approches se combinent. L’analyse du trafic réseau et des journaux de la passerelle révèle les endpoints réellement appelés. L’examen des dépôts de code et des fichiers de spécification, par exemple OpenAPI, expose les API documentées. Des outils de découverte d’API analysent le trafic pour repérer les API fantômes, non documentées, et les API zombies, anciennes versions toujours en ligne. L’inventaire n’est pas un projet ponctuel mais un processus continu, car de nouvelles API apparaissent à chaque déploiement.
Références
[1] OWASP API Security Top 10, édition 2023, classement des risques majeurs des API. [2] OWASP, API1:2023 Broken Object Level Authorization (BOLA), description du risque numéro un. [3] ENISA, Threat Landscape 2024, panorama annuel des menaces en Europe. [4] CERT-FR (ANSSI), publications de renseignement sur les menaces (CTI). [5] Directive (UE) 2022/2555 (NIS2), exigences de sécurité du développement et d’analyse des risques. [6] OWASP, REST Security Cheat Sheet, bonnes pratiques de sécurisation des API REST.
Sources primaires : OWASP API Top 10 2023, OWASP BOLA, ENISA Threat Landscape 2024, CERT-FR CTI, EUR-Lex NIS2, OWASP REST Security Cheat Sheet.