Gouvernance de la sécurité des API : éléments probants ISO 27001 pour 2026

Le constat d’audit API qui précède l’incident

Maria, RSSI d’une fintech SaaS en forte croissance, ouvre un e-mail de l’auditeur principal trois semaines avant l’évaluation annuelle. Le message est direct :

« Nous procéderons à une revue approfondie de votre cadre de gestion des risques liés aux tiers prestataires de services TIC et de son alignement avec DORA, NIS2 et GDPR, avec une attention particulière portée à votre écosystème d’API. Veuillez fournir l’inventaire, le modèle d’authentification, les éléments probants de limitation de débit et la couverture de journalisation pour les API de production et les API partenaires. »

Deux jours plus tard, l’audit interne envoie un second message :

« Nous avons identifié 47 points de terminaison API publics absents de l’inventaire des actifs. Quatre acceptent des clés API sans élément probant de rotation. Une intégration partenaire ne comporte aucune limitation de débit. La journalisation est incohérente entre les services de production. Veuillez fournir les éléments probants ISO 27001, GDPR et NIS2 d’ici vendredi. »

Il n’y a pas de demande de rançon. Pas de violation rendue publique. Pas de réclamation client. Mais le constat est sérieux, car il révèle une lacune de gouvernance que les attaquants exploitent déjà. Les API constituent désormais le véritable périmètre. Elles relient les paiements, l’onboarding client, l’identité, les portails clients, les services fournisseurs, les applications mobiles, les charges de travail cloud, les plateformes analytiques et les moteurs de risque externalisés.

Un quasi-incident rend le sujet plus difficile à ignorer. Un développeur junior, travaillant sous pression, a exposé sur Internet une API de préproduction sans authentification. Elle contenait des données client réalistes et pseudonymisées. L’équipe Red Team l’a trouvée en premier, mais la direction a posé la question évidente : qu’y a-t-il d’autre d’exposé ?

En 2026, la gouvernance de la sécurité des API n’est plus une simple checklist développeur. Les RSSI, les responsables conformité, les auditeurs internes et les conseils d’administration doivent prouver que les API sont connues, attribuées à un responsable, authentifiées, surveillées, soumises à une limitation de débit, testées, appréciées au regard des risques et intégrées au processus de notification des incidents. Les mêmes éléments probants doivent souvent satisfaire des attentes d’assurance alignées sur ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 et COBIT.

La plupart des organisations disposent déjà d’outils techniques : passerelles API, fournisseurs d’identité, plateformes SIEM, WAF, journaux cloud, maillages de services, pipelines CI/CD et systèmes de tickets. Ce qui leur manque souvent, c’est le récit de contrôle. Quelles API sont dans le périmètre ? Qui approuve les nouvelles API ? Quels journaux prouvent les échecs d’authentification ? Quel registre montre les dépendances des API vis-à-vis de tiers ? Pourquoi les limites de débit diffèrent-elles entre les API client, administrateur et machine-à-machine ?

L’approche de Clarysec consiste à traiter la gouvernance de la sécurité des API comme un système d’éléments probants transversal à la conformité, et non comme une activité d’ingénierie ponctuelle. Si une API peut exposer des données, modifier un processus métier, authentifier un utilisateur, déclencher un paiement, appeler un fournisseur ou soutenir un service réglementé, elle doit être intégrée au modèle d’éléments probants du SMSI.

Pourquoi la gouvernance des API relève désormais du conseil d’administration

NIS2 fait de la gouvernance de la cybersécurité une responsabilité de l’organe de direction. Article 20 exige que les organes de direction approuvent les mesures de gestion des risques de cybersécurité, en supervisent la mise en œuvre et suivent une formation leur permettant de comprendre les cyberrisques et leur impact sur les services. Article 21 exige des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées, incluant l’analyse des risques, les politiques de sécurité, la gestion des incidents, la continuité d’activité, la sécurité de la chaîne d’approvisionnement, l’acquisition et le développement sécurisés, la gestion des vulnérabilités, l’évaluation de l’efficacité, l’hygiène cyber, la cryptographie, le contrôle d’accès, la gestion des actifs et, le cas échéant, l’authentification multifacteur ou continue.

Pour la gouvernance des API, cela signifie que les API publiques, les API partenaires, les API d’administration et les API internes de microservices peuvent faire partie de la fourniture de services réglementés. NIS2 peut s’appliquer aux fournisseurs de services d’informatique en nuage, aux fournisseurs de services de centres de données, aux réseaux de diffusion de contenu, aux prestataires de services de confiance, aux réseaux et services de communications électroniques publics, ainsi qu’aux prestataires de gestion de services TIC tels que les MSP et MSSP, selon le secteur, la taille, la criticité et la classification retenue par l’État membre.

DORA ajoute une lecture propre au secteur financier. Il s’applique depuis le 17 janvier 2025 et établit des exigences uniformes en matière de gestion des risques liés aux TIC, de notification des incidents liés aux TIC, de tests de résilience opérationnelle numérique, de partage d’informations et de gestion des risques liés aux prestataires tiers de services TIC. Article 5 exige que l’organe de direction définisse, approuve et supervise le cadre de gestion des risques liés aux TIC, et en demeure responsable. Article 8 impose l’identification, la classification et la documentation des fonctions métier soutenues par les TIC, des actifs informationnels, des actifs TIC, des dépendances, des processus soutenus par des tiers, des actifs critiques, des inventaires et des risques TIC liés aux systèmes hérités.

En matière d’API, une API d’initiation de paiement, une API de scoring de fraude, une API d’onboarding client ou une API KYC externalisée n’est pas seulement un point de terminaison. C’est un actif TIC et une dépendance qui soutiennent une fonction métier.

GDPR complète le cadre. Les API qui transmettent des identifiants, des données de compte, des identifiants d’appareil, de la télémétrie comportementale, des données biométriques, des données de santé ou des profils financiers peuvent traiter des données à caractère personnel. Le principe de responsabilité de GDPR impose aux responsables du traitement de démontrer la conformité à la licéité, à la limitation des finalités, à la minimisation des données, à la limitation de la conservation, à l’intégrité et à la confidentialité. Article 32 impose la sécurité du traitement, tandis que Articles 33 et 34 reposent sur des éléments probants fiables lorsqu’une violation de données à caractère personnel survient.

Le conseil d’administration n’a pas besoin de captures de paquets, mais il doit avoir l’assurance que l’organisation sait quelles API sont importantes, quelles données elles traitent, de quels fournisseurs elles dépendent, comment les abus sont empêchés, comment les incidents sont détectés et comment la conformité peut être démontrée.

Commencer par l’inventaire des API

La plupart des défaillances d’API commencent par une défaillance d’inventaire. Un backend mobile obsolète fonctionne encore en production. Une intégration partenaire temporaire devient permanente. Une fonction cloud expose un nouveau point de terminaison. Une API interne devient accessible depuis Internet après une modification d’un répartiteur de charge. Rien n’apparaît dans la CMDB ; rien ne fait donc l’objet d’une revue d’authentification, de normes de journalisation, de seuils de limitation de débit, d’évaluation fournisseur ou de classification de conservation.

La première question d’audit est généralement simple : « Puis-je consulter votre inventaire des API ? »

Clarysec traite l’inventaire des API comme une composante de l’inventaire des actifs du SMSI. Dans le Zenith Blueprint : feuille de route en 30 étapes pour auditeurs Zenith Blueprint, phase « Controls in Action », Étape 22, les lignes directrices relatives au contrôle ISO/IEC 27002:2022 5.9 expliquent :

« Aucune organisation ne peut protéger ce dont elle ignore l’existence. Le contrôle 5.9 formalise ce principe fondamental en exigeant l’établissement et la tenue à jour d’un inventaire actualisé de toutes les informations et de tous les actifs associés pertinents pour le SMSI. »

La même étape inclut les actifs logiques tels que « comptes utilisateurs, identifiants, clés, licences logicielles, API » et les actifs liés aux services tels que les plateformes SaaS et le stockage externalisé. Le Zenith Blueprint qualifie l’inventaire de « système nerveux central de votre SMSI », car il alimente l’attribution des accès, le chiffrement, la sauvegarde, la journalisation, la classification et la conservation.

La Politique de gestion des actifs d’entreprise de Clarysec Politique de gestion des actifs transforme cela en exigence de gouvernance :

« Le responsable des actifs informatiques doit tenir à jour un inventaire des actifs complet et centralisé couvrant tous les actifs informationnels utilisés par l’organisation ou connectés à celle-ci. »

Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.1.1.

Pour les PME, la Politique de gestion des actifs - PME de Clarysec Politique de gestion des actifs - PME inclut explicitement les actifs numériques pertinents pour les API :

« Identifiants et services numériques : noms de domaine, certificats numériques, clés API, comptes de messagerie, connexions cloud »

Extrait de la section « Champ d’application », clause de politique 2.2.4.

Cette formulation est importante. Dans de nombreux audits, le point de terminaison API apparaît dans une passerelle, le jeton dans un coffre de secrets, le certificat dans un compte cloud et le flux de données dans un registre de protection des données. Un inventaire des API défendable les relie.

Dans Zenith Controls : guide transverse de conformité Zenith Controls, le contrôle ISO/IEC 27002:2022 5.9, Inventaire des informations et autres actifs associés, est classé comme contrôle préventif soutenant la confidentialité, l’intégrité et la disponibilité. Son concept de cybersécurité est Identifier, sa capacité opérationnelle est la gestion des actifs, et ses domaines de sécurité sont la gouvernance, l’écosystème et la protection. Cela aide les auditeurs à considérer l’inventaire des API comme un contrôle préventif de gouvernance, et non comme une simple tenue administrative.

Prouver que chaque identité API est intentionnelle

Une fois l’inventaire établi, la question suivante est prévisible : qui, ou quoi, peut appeler ces API ?

Les API modernes authentifient des utilisateurs humains, des applications mobiles, des comptes de service, des tâches CI/CD, des systèmes partenaires, des charges de travail, des bots, des intégrations, des pipelines de données et des plateformes tierces. Les clés API faibles, les jetons porteurs à longue durée de vie, l’absence de TLS mutuel, les périmètres OAuth surdimensionnés et les secrets codés en dur créent tous une exposition en audit.

Le Zenith Blueprint, phase « Controls in Action », Étape 19, traite du contrôle ISO/IEC 27002:2022 8.5, Authentification sécurisée :

« L’authentification constitue la première ligne de défense, et la plus critique, entre un acteur malveillant et vos systèmes, données et services. Si l’authentification est faible, tout le reste — chiffrement, surveillance, segmentation — peut être contourné. »

La même étape met en évidence l’authentification machine-à-machine. Les clés, certificats et jetons doivent être protégés rigoureusement, les identifiants ne doivent pas être intégrés dans le code, et des solutions de gestion des secrets ou des coffres doivent être utilisées pour le stockage sécurisé et la rotation.

La Politique relative aux exigences de sécurité des applications d’entreprise de Clarysec Politique relative aux exigences de sécurité des applications l’intègre directement à la gouvernance des API :

« Toutes les interfaces de programmation d’applications (API), microservices et intégrations externes doivent être sécurisés au moyen de : »

Extrait de la section « Exigences de gouvernance », clause de politique 5.3.

Elle précise ensuite :

« Application d’une authentification forte, telle qu’OAuth 2.0 et TLS mutuel »

Extrait de la section « Exigences de gouvernance », clause de politique 5.3.1.

Pour les organisations plus petites, la Politique relative aux exigences de sécurité des applications - PME de Clarysec Politique relative aux exigences de sécurité des applications - PME fournit le référentiel minimal :

« Contrôles d’authentification : les applications doivent imposer une authentification forte, incluant une robustesse minimale des mots de passe, le verrouillage du compte après des tentatives échouées et des délais d’expiration de session. »

Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.1.1.2.

Pour les API, traduisez ces exigences en dossier d’éléments probants d’authentification :

1. Inventaire des API filtré par API exposées à Internet, API partenaires, API d’administration et API internes.
2. Matrice d’authentification présentant OAuth 2.0, mTLS, les requêtes signées, les mécanismes d’autorisation de passerelle ou l’identité du maillage de services.
3. Registre des clients et des périmètres OAuth avec responsable, finalité, expiration, approbation et date de dernière revue.
4. Éléments probants de gestion des secrets montrant le stockage, l’accès, la rotation et la révocation.
5. Revue des accès API à privilèges pour les points de terminaison d’administration et les comptes de service de production.
6. Journaux des échecs d’authentification et règles d’alerte.
7. Résultats de tests pour les scénarios de jeton manquant, jeton expiré, audience incorrecte, périmètre incorrect et rejeu.

Dans Zenith Controls, le contrôle ISO/IEC 27002:2022 8.5, Authentification sécurisée, est cartographié comme contrôle préventif soutenant la confidentialité, l’intégrité et la disponibilité. Son concept de cybersécurité est Protéger, sa capacité opérationnelle est la gestion des identités et des accès, et son domaine de sécurité est la protection.

NIS2 Article 21 soutient cette approche au travers du contrôle d’accès, de la cryptographie et de l’authentification multifacteur ou continue, le cas échéant. DORA attend des entités financières qu’elles maintiennent des contrôles protégeant l’authenticité, l’intégrité, la disponibilité et la confidentialité. GDPR Article 32 transforme une authentification API faible en enjeu de sécurité du traitement, en particulier lorsque des données à caractère personnel sont exposées.

Traiter la limitation de débit comme un élément probant de résilience

Une authentification forte est nécessaire, mais elle ne suffit pas. Un client authentifié peut tout de même abuser d’une API. Les attaquants utilisent les API pour le credential stuffing, l’énumération, le scraping, la pulvérisation de jetons, le bombardement de réinitialisation de mot de passe, l’abus transactionnel et le déni de service.

La limitation de débit était auparavant considérée comme une fonctionnalité de performance. En 2026, elle constitue un élément probant de sécurité, de protection des données et de résilience.

La Politique relative aux exigences de sécurité des applications de Clarysec indique :

« Limitation de débit et prévention des abus »

Extrait de la section « Exigences de gouvernance », clause de politique 5.3.2.

Le Zenith Blueprint, phase « Controls in Action », Étape 20, relative au contrôle ISO/IEC 27002:2022 8.26, Exigences de sécurité des applications, explique que les exigences de sécurité des applications doivent être précises et actionnables. Il demande si une application doit résister aux attaques par injection, aux connexions par force brute ou aux tentatives de déni de service. Il donne également l’exemple spécifique d’une nouvelle API qui doit inclure la validation des jetons d’accès et l’assainissement des entrées, et précise que les plateformes exposées au public peuvent exiger une validation plus stricte, l’analyse du comportement utilisateur et la limitation de débit.

Un enregistrement défendable de limitation de débit doit expliquer non seulement que le bridage existe, mais aussi pourquoi les seuils ont été retenus, qui a approuvé les exceptions et comment les alertes sont surveillées.

Pour NIS2, cela soutient le développement sécurisé, l’évaluation de l’efficacité, la continuité d’activité et la prévention des incidents. Pour DORA, la limitation de débit se rattache à la gestion des risques liés aux TIC, à la détection d’anomalies, aux tests de résilience et à la continuité des fonctions critiques ou importantes. Pour GDPR, elle soutient la minimisation des données et la protection contre les accès excessifs ou illicites, notamment lorsque le scraping d’API pourrait exposer des données à caractère personnel.

Faire de la journalisation la couche de preuve

Lorsqu’un incident API survient, la première vraie question n’est pas « Avez-vous un SIEM ? ». C’est : « Pouvez-vous reconstituer ce qui s’est passé ? »

Les journaux d’API doivent capturer les échecs d’authentification, les refus d’autorisation, les revendications de jetons, l’identité du client, la source, le point de terminaison, la méthode, le résultat de la requête, les changements administratifs, les accès à des données à haut risque, les événements de limitation de débit, les volumes anormaux, les changements de configuration et les erreurs pertinentes pour la sécurité. Ils doivent également éviter de journaliser des secrets, des jetons porteurs ou des données à caractère personnel inutiles.

Le Zenith Blueprint, phase « Controls in Action », Étape 19, relative au contrôle ISO/IEC 27002:2022 8.15, Journalisation, indique :

« La journalisation est le cœur vital de tout environnement informatique sécurisé. Sans elle, les incidents restent invisibles, la responsabilité s’estompe et les relations de cause à effet disparaissent. »

Il explique également que la journalisation porte sur la traçabilité, et que des journaux utiles doivent être stockés de manière sécurisée, surveillés, revus et protégés contre l’altération.

La Politique relative aux exigences de sécurité des applications - PME de Clarysec exige :

« Journalisation d’audit : les applications doivent journaliser les événements d’authentification (connexions, déconnexions et tentatives échouées), l’accès aux données et les changements administratifs. »

Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.1.1.7.

La Politique de journalisation et de surveillance - PME de Clarysec Politique de journalisation et de surveillance - PME établit la catégorie de gouvernance de la journalisation :

« Types de journaux requis »

Extrait de la section « Exigences de gouvernance », clause de politique 5.4.

Pour les API hébergées dans le cloud, la Politique d’utilisation du cloud d’entreprise de Clarysec Politique d’utilisation du cloud renforce l’exigence :

« Les journaux doivent capturer : »

Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.5.2.

Dans Zenith Controls, le contrôle ISO/IEC 27002:2022 8.15, Journalisation, est cartographié comme contrôle détectif soutenant la confidentialité, l’intégrité et la disponibilité. Son concept de cybersécurité est Détecter, sa capacité opérationnelle est la gestion des événements de sécurité de l’information, et ses domaines de sécurité sont la protection et la défense. Cela fait de la journalisation le lien entre la politique et la preuve.

NIS2 Article 23 exige une notification échelonnée des incidents significatifs : alerte précoce dans les 24 heures suivant la prise de connaissance, notification d’incident dans les 72 heures, rapports intermédiaires si demandés et rapport final dans le mois suivant la notification. Pour les prestataires de services de confiance affectés dans la fourniture de services de confiance, une notification dans les 24 heures suivant la prise de connaissance est requise.

DORA Articles 17 à 19 exigent une gestion des incidents liés aux TIC comprenant des indicateurs d’alerte précoce, une classification par gravité et criticité, l’escalade, la journalisation, le suivi des causes racines et la notification des incidents majeurs liés aux TIC au moyen de rapports initiaux, intermédiaires et finaux. L’évaluation des violations au titre de GDPR dépend également des journaux pour déterminer si des données à caractère personnel ont été consultées, quelles personnes ont été affectées et si des obligations de notification sont déclenchées.

Constituer un dossier d’éléments probants API en cinq jours ouvrés

L’objectif d’un sprint rapide n’est pas de corriger toute la sécurité des API en une semaine. L’objectif est de créer une base défendable, d’identifier les lacunes et d’engager le traitement des risques.

Jour 1 : établir le registre des API

Exportez les routes depuis les passerelles API, les maillages de services, les répartiteurs de charge cloud, les fonctions serverless, les référentiels OpenAPI et les manifestes de déploiement CI/CD. Normalisez-les dans un registre API unique avec le point de terminaison, l’environnement, le responsable, le processus métier, la classification des données, l’indicateur de données à caractère personnel, la méthode d’authentification, la limite de débit, le statut de journalisation, la dépendance fournisseur, la criticité et la date de dernière revue.

Utilisez la clause 6.1.1 de la Politique de gestion des actifs et l’Étape 22 du Zenith Blueprint comme ancrage de gouvernance.

Jour 2 : classifier les lacunes d’authentification

Créez une matrice d’authentification. Signalez les API utilisant des clés API statiques, des jetons à longue durée de vie, sans validation d’audience, sans validation de périmètre, sans mTLS pour les intégrations partenaires, avec des comptes de service partagés ou sans élément probant de rotation.

Cartographiez les constats avec la clause 5.3.1 de la Politique relative aux exigences de sécurité des applications et l’Étape 19 du Zenith Blueprint. Enregistrez chaque lacune comme un risque avec un responsable, une trajectoire de traitement et une date cible.

Jour 3 : prouver la limitation de débit et les contrôles anti-abus

Pour les API publiques, partenaires et d’administration, collectez les politiques de passerelle, les règles WAF, les contrôles anti-bots, les paramètres de quota et les seuils d’alerte. Lorsque les contrôles sont absents, enregistrez les contrôles compensatoires ou le traitement des risques ouvert.

Utilisez la clause 5.3.2 de la Politique relative aux exigences de sécurité des applications comme autorité de politique. Pour les API critiques, reliez les seuils à l’impact sur le service, au préjudice client et aux attentes de résilience DORA ou NIS2.

Jour 4 : valider la couverture de journalisation

Échantillonnez les journaux des API à haut risque. Confirmez que les journaux capturent l’authentification réussie, l’échec d’authentification, le refus d’autorisation, l’accès aux données, le changement administrateur, l’événement de limitation de débit, l’identité source et l’identifiant de corrélation. Vérifiez la synchronisation temporelle, la conservation, le contrôle d’accès et la protection contre l’altération.

Si les journaux contiennent des jetons, des secrets ou des données à caractère personnel excessives, ouvrez des actions de remédiation relatives à la protection des données et à la sécurité.

Jour 5 : livrer le dossier de réponse à l’audit

Livrez un ensemble concis d’éléments probants :

• Export de l’inventaire des API et synthèse des responsables.
• Registre des risques API avec plan de traitement des risques.
• Matrice d’authentification et éléments probants de revue des jetons.
• Éléments probants de limitation de débit et exceptions approuvées.
• Rapport de couverture de journalisation et captures d’écran des tableaux de bord SIEM.
• Playbook de classification des incidents pour les abus d’API.
• Cartographie transverse de conformité vers les vues d’audit alignées sur ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 et COBIT.

Le changement important est que chaque livrable porte un récit de contrôle. Le registre API soutient la gestion des actifs. L’authentification soutient le contrôle d’accès. Les limites de débit soutiennent la sécurité des applications et la résilience. Les journaux soutiennent la détection, la réponse aux incidents et la responsabilité.

Cartographie transverse de conformité pour la gouvernance des API

La plus grande erreur consiste à créer des ensembles d’éléments probants séparés pour chaque référentiel. La gouvernance des API fonctionne mieux comme un modèle de contrôle unique avec plusieurs lectures réglementaires.

ISO/IEC 27001:2022 fournit le système de management qui relie les éléments probants. Clauses 4.1 à 4.4 exigent que l’organisation définisse le contexte et le périmètre du SMSI, y compris les parties intéressées, les obligations légales, réglementaires et contractuelles, ainsi que les interfaces ou dépendances avec d’autres organisations. Clauses 5.1 à 5.3 placent la responsabilité auprès de la direction. Clauses 6.1.1 à 6.1.3 créent le processus d’appréciation des risques, de traitement des risques et de Déclaration d’applicabilité. Clause 8.1 exige la planification et la maîtrise opérationnelles, y compris la maîtrise des processus, produits ou services fournis par des tiers et pertinents pour le SMSI.

Pour la gouvernance des API, cela signifie qu’une API de paiement tierce, une API d’identité cloud ou une API de détection de fraude externalisée n’est pas hors conformité parce qu’elle est externe. C’est une interface et une dépendance qui doivent être intégrées au périmètre, faire l’objet d’une appréciation des risques et être maîtrisées.

NIST CSF 2.0 ajoute une lecture utile pour la direction. Sa fonction GOVERN aide les organisations à définir les attentes des parties prenantes, les obligations légales, l’appétence au risque et les risques liés à la chaîne d’approvisionnement. Son approche par Profiles soutient un Current Profile, un Target Profile, un plan de lacunes priorisé et un cycle d’amélioration continue. C’est exactement la façon dont un sprint de gouvernance des API doit fonctionner.

COBIT 2019 peut soutenir la lecture managériale en reliant les contrôles API aux objectifs de gouvernance, à la propriété des contrôles, à la continuité de service, à la surveillance de la sécurité, au reporting des risques et au suivi des actions. L’objectif n’est pas de forcer les API dans un seul référentiel, mais de montrer qu’un même modèle d’éléments probants répond à plusieurs questions d’assurance.

Comment les auditeurs testent la gouvernance des API

Un programme robuste anticipe le regard de l’auditeur. Les mêmes éléments probants seront testés différemment selon le référentiel.

Clarysec recommande la triangulation des éléments probants. Ne montrez pas uniquement la politique. Montrez la politique, les éléments probants de mise en œuvre et les éléments probants opérationnels.

Par exemple :

• Politique : les API doivent utiliser OAuth 2.0 ou mTLS lorsque cela est approprié.
• Configuration : la route de passerelle API montre la validation JWT et l’audience autorisée.
• Éléments probants opérationnels : les tentatives avec jeton invalide sont journalisées et l’alerte est active.
• Éléments probants de revue : la revue du client OAuth est terminée avec validation du responsable.
• Éléments probants de risque : une exception relative à une API héritée dispose de contrôles compensatoires et d’une échéance de traitement.

C’est beaucoup plus solide qu’une réponse composée uniquement de captures d’écran.

Pièges fréquents de gouvernance des API

Le problème le plus courant n’est pas que les API soient totalement non sécurisées. C’est que la sécurité est incohérente.

Une équipe utilise correctement les périmètres OAuth, une autre utilise une clé API partagée. Un service journalise l’accès aux données, un autre ne journalise que les erreurs serveur. Une intégration partenaire utilise mTLS, une autre repose sur un jeton porteur à longue durée de vie. Des limites de débit existent pour les points de terminaison publics, mais pas pour les API client authentifiées où le scraping peut se produire. La CMDB répertorie l’application, mais pas ses API, jetons, certificats, catégories de données ou fournisseurs.

Les pièges récurrents comprennent :

• API fantômes déployées via des fonctions serverless ou des routes de test temporaires.
• Clés API stockées dans des variables CI/CD sans rotation documentée.
• Journalisation capturant des jetons, des secrets ou des données à caractère personnel inutiles.
• Absence d’identifiant de corrélation entre les journaux de passerelle, d’application et de base de données.
• Exceptions de limitation de débit accordées de manière informelle à de grands clients.
• API partenaires sans notification contractuelle d’incident ni droits d’audit.
• Absence de classification d’incident spécifique aux API pour l’énumération, le scraping ou l’abus de jetons.
• Absence de cartographie entre les flux de données API et les registres des traitements GDPR.
• Tests de sécurité concentrés sur l’interface web alors que les API restent non testées.
• Rapports au conseil d’administration présentant la « sécurité des applications » sans indicateurs de risque spécifiques aux API.

Ces problèmes peuvent être résolus, mais seulement si l’organisation traite la gouvernance des API comme un domaine de contrôle managé.

Transformer la sécurité des API en gouvernance prête pour l’audit

Si votre prochain audit demande des éléments probants de sécurité des API, ne commencez pas par collecter des captures d’écran aléatoires. Commencez par le récit de contrôle.

Clarysec peut vous aider à le construire avec :

• Zenith Blueprint Zenith Blueprint pour structurer la mise en œuvre autour de l’inventaire des actifs, de l’authentification sécurisée, des exigences de sécurité des applications et de la journalisation.
• Zenith Controls Zenith Controls pour cartographier les contrôles ISO/IEC 27002:2022 tels que 5.9, 8.5, 8.15 et 8.26 avec les attentes transverses de conformité et les perspectives d’audit.
• Les politiques Clarysec, notamment la Politique de gestion des actifs Politique de gestion des actifs, la Politique relative aux exigences de sécurité des applications Politique relative aux exigences de sécurité des applications, la Politique d’utilisation du cloud Politique d’utilisation du cloud, la Politique de gestion des actifs - PME Politique de gestion des actifs - PME, la Politique relative aux exigences de sécurité des applications - PME Politique relative aux exigences de sécurité des applications - PME et la Politique de journalisation et de surveillance - PME Politique de journalisation et de surveillance - PME.

Une prochaine étape pratique consiste à lancer un Clarysec API Governance Evidence Sprint : inventorier vos API, classifier l’authentification, vérifier la limitation de débit, valider la journalisation, cartographier les dépendances vis-à-vis de tiers et produire un dossier d’éléments probants prêt pour ISO 27001, avec des vues d’audit alignées sur NIS2, DORA, GDPR, NIST CSF 2.0 et COBIT.

Les API sont le point de rencontre entre la logique métier, les données client et les dépendances vis-à-vis de tiers. En 2026, elles méritent plus qu’une protection technique. Elles nécessitent une gouvernance capable de résister à un audit, de soutenir une réponse à l’autorité de régulation et d’aider vos équipes à détecter les abus avant vos clients.