Qu'est-ce qu'un audit de sécurité d'API ?

Qu'est-ce qu'un audit de sécurité d'API ?

Un audit de sécurité d'API est un examen structuré de la conception, de l'implémentation et de la configuration d'une API au regard d'un ensemble défini d'exigences de sécurité, afin de trouver les faiblesses avant un attaquant. Il combine un inventaire des endpoints, des analyses automatisées et des tests manuels, et se termine par une liste priorisée de constats avec corrections et un nouveau test.

Dans la pratique, les termes se recoupent. Une analyse est automatisée et trouve des familles de failles connues. Un test d'intrusion tente d'exploiter les faiblesses. Un audit confronte l'API à un référentiel déclaré et s'appuie en général sur les deux, avec un regard sur la conception, la configuration et la documentation. Convenez du périmètre et du vocabulaire avec le prestataire ou le demandeur.

Les référentiels utilisés pour un audit

La plupart des audits partent de l'OWASP API Security Top 10 (2023), une liste de sensibilisation des risques les plus critiques pour les API (les intitulés sont couramment employés en anglais) :

1. API1:2023 Broken Object Level Authorization
2. API2:2023 Broken Authentication
3. API3:2023 Broken Object Property Level Authorization
4. API4:2023 Unrestricted Resource Consumption
5. API5:2023 Broken Function Level Authorization
6. API6:2023 Unrestricted Access to Sensitive Business Flows
7. API7:2023 Server Side Request Forgery
8. API8:2023 Security Misconfiguration
9. API9:2023 Improper Inventory Management
10. API10:2023 Unsafe Consumption of APIs

Pour une liste de contrôle plus poussée, l'OWASP Application Security Verification Standard (ASVS, version 5.0.0 publiée le 30 mai 2025) énumère des exigences de sécurité et se veut une base pour tester les contrôles techniques de sécurité des applications web. L'OWASP Web Security Testing Guide explique comment les tester. Notre entrée sur les principaux risques de sécurité des API détaille les risques eux-mêmes, et sécurité des API couvre le sujet plus large.

Un exemple : autorisation défaillante au niveau des objets

Le scénario propre à l'OWASP pour API1 est une API de commerce en ligne avec un endpoint du type /shops/{shopName}/revenue_data.json. Un attaquant récupère la liste des noms de boutiques via un autre endpoint et les substitue un à un dans l'URL. Si le serveur vérifie seulement que l'appelant est connecté, et non que la boutique lui appartient, le script lit le chiffre d'affaires de milliers de boutiques. Un scanner le repère rarement, car chaque réponse est un 200 valide. Un auditeur le teste en appelant l'endpoint avec un utilisateur et les identifiants d'un autre. Le correctif est un contrôle de propriété dans chaque fonction qui reçoit un ID fourni par le client.

Déroulement d'un audit

1. Périmètre et inventaire. Listez toutes les API et versions : fichiers OpenAPI, journaux de la passerelle, code et trafic. Voir découverte d'API et prolifération d'API. On ne peut pas auditer un endpoint dont personne ne connaît l'existence.
2. Choisir le référentiel. OWASP API Top 10, ASVS ou votre propre politique.
3. Analyse automatisée. Lancez un scanner sur un environnement de test pour couvrir vite les familles de failles connues.
4. Tests manuels. Les défauts d'autorisation exigent de vrais comptes de test avec des rôles différents, afin que l'auditeur puisse demander : "l'utilisateur A peut-il atteindre les données de l'utilisateur B ?"
5. Qualification. Évaluez chaque constat selon l'impact et la facilité d'exploitation, et désignez des responsables.
6. Corriger et retester. Vérifiez que le correctif ferme le problème sans en casser un autre.
7. Rapport. Constats, preuves, gravité et remédiation, avec un court résumé pour les non-techniciens.

Ce qui est vérifié

• Authentification : validation des jetons, expiration, gestion des identifiants, protection contre la force brute.
• Autorisation : contrôles au niveau de l'objet, de la propriété et de la fonction sur chaque endpoint, pas seulement à la connexion.
• Traitement des entrées : injection, limites de taille des requêtes, validation de schéma, requêtes côté serveur construites à partir de données utilisateur.
• Limites de ressources : limites de débit, plafonds de pagination, opérations coûteuses.
• Exposition de données : champs renvoyés que l'appelant ne devrait pas voir, jetons ou données personnelles dans les journaux, messages d'erreur qui divulguent des détails internes.
• Configuration : chiffrement du transport, CORS, modes de débogage, identifiants par défaut.
• Inventaire et tiers : anciennes versions oubliées et traitement des données issues d'autres API appelées.

Erreurs courantes

• N'auditer que les endpoints documentés. Les anciennes versions et les routes non documentées sont là où se cachent les surprises.
• Tester avec un seul compte administrateur. Les défauts d'autorisation n'apparaissent qu'en changeant d'identité.
• Limites de débit uniquement sur la passerelle. Si l'origine est joignable directement, la limite ne sert à rien.
• Un audit ponctuel. L'API change à chaque sprint, un rapport propre vieillit vite.
• Scanner sans autorisation ou en production. Obtenez une autorisation écrite et préférez un environnement de test. Voir le comparatif des outils de test d'intrusion.
• Pas de nouveau test. Un constat est clos quand il est vérifié, pas quand le ticket est fermé.

Lien avec la surveillance et les tests de charge

LoadFocus n'est pas un auditeur de sécurité et ne recherche pas de vulnérabilités. Il peut en revanche continuer à surveiller le comportement après qu'un audit a corrigé quelque chose. La surveillance d'API exécute des contrôles scriptés à intervalle régulier (toutes les 5 minutes avec l'offre gratuite) depuis plusieurs de ses 25 régions et peut vérifier le code de statut, le corps et les en-têtes : un contrôle qui attend qu'une requête sans jeton soit refusée échouera si un déploiement ultérieur l'autorise. Les contrôles en plusieurs étapes peuvent enchaîner des requêtes, par exemple se connecter puis appeler un autre endpoint. Pour la consommation de ressources, un test de charge d'API gratuit montre comment un endpoint public se comporte sous volume (requêtes GET uniquement, jusqu'à 25 utilisateurs virtuels depuis un site) ; ne testez en charge que des systèmes qui vous appartiennent ou pour lesquels vous avez l'autorisation. Pour une recherche plus poussée sur le trafic réel, voir chasse aux menaces sur les API.

Questions fréquentes : audits de sécurité d'API

À quelle fréquence faut-il auditer une API ?

Avant la mise en production, après des changements importants d'authentification ou de traitement des données, puis à intervalle régulier. Comme les API changent sans cesse, beaucoup d'équipes ajoutent des contrôles automatisés entre deux audits complets plutôt que de s'en remettre à un rapport par an.

Quelle différence entre audit de sécurité d'API et test d'intrusion ?

Les termes se recoupent. Un test d'intrusion cherche surtout à exploiter les faiblesses et couvre souvent plus que l'API. Un audit confronte à un référentiel déclaré et couvre la conception, la configuration et les processus en plus de l'exploitabilité. Confirmez ce que comprend chaque prestation avant de commencer.

Les API uniquement internes doivent-elles être auditées ?

Oui. Les API internes sont accessibles à quiconque prend pied dans le réseau ou compromet un service, et méritent la même authentification, la même autorisation et la même journalisation que les API publiques.

Que faut-il préparer pour un audit ?

Les spécifications d'API à jour, un inventaire des endpoints et des versions, des comptes de test pour chaque rôle, un environnement de test et une liste des problèmes connus. Plus l'inventaire est complet, moins on perd de temps à la découverte.

Un scanner automatique peut-il remplacer un audit ?

Non. Les scanners couvrent vite les familles de failles connues, mais ils ne savent pas à qui chaque objet devrait appartenir : des défauts comme l'autorisation défaillante au niveau des objets demandent donc en général des tests manuels avec plusieurs identités.