API Security : sécuriser les interfaces d'API

L'API Security désigne l'ensemble des pratiques visant à sécuriser les interfaces d'API exposées par une application ou une infrastructure. Une API (Application Programming Interface) constitue un point d'entrée structuré vers la logique métier et les données d'un système. Les interfaces REST et GraphQL sont aujourd'hui omniprésentes dans les architectures modernes, ce qui en fait des cibles prioritaires. Les vulnérabilités les plus critiques sont recensées dans l'OWASP API Top 10 : Broken Object Level Authorization (BOLA), authentification défaillante, exposition excessive de données, manque de contrôle des ressources ou encore injections. Un endpoint API mal configuré peut exposer directement des données sensibles, contourner des contrôles d'accès ou permettre des actions non autorisées. Contrairement aux interfaces web traditionnelles, les API répondent de façon prévisible à des requêtes structurées, ce qui facilite leur exploration automatisée. La surface d'attaque inclut les endpoints non documentés, les versions obsolètes non désactivées et les tokens d'authentification mal protégés.

La détection des attaques contre les API repose sur l'analyse fine des logs HTTP et des événements applicatifs. Côté Blue Team, il faut surveiller les codes de réponse inhabituels : une multiplication de 401, 403 ou 422 sur un même endpoint signale souvent une énumération ou un fuzzing actif. Les anomalies de volume, comme un pic de requêtes sur un endpoint spécifique, indiquent un abus de rate limiting ou un scraping. Les outils SIEM comme Splunk ou Elastic Security permettent de corréler ces événements avec des sources d'IP connues comme malveillantes via des flux Threat Intelligence. Les WAF applicatifs (ModSecurity, AWS WAF) génèrent des alertes sur les tentatives d'injection ou les payloads malformés. En complément, les solutions de type API Gateway (Kong, Apigee) journalisent nativement les paramètres de chaque requête, facilitant la détection de BOLA par comparaison d'identifiants dans les URLs. L'activation du logging de l'authentification OAuth (événements de refresh token, révocation, scope anormal) permet également de détecter des compromissions de sessions API actives.

En contexte Red Team ou pentest, l'audit d'API commence par la phase de reconnaissance : collecte de la documentation Swagger/OpenAPI, découverte d'endpoints non référencés via des outils comme Arjun ou kiterunner, et analyse du trafic intercepté avec Burp Suite. Le fuzzing des paramètres avec ffuf ou Postman permet d'identifier des comportements inattendus. L'exploitation du BOLA consiste à remplacer un identifiant dans l'URL (ex : /api/users/1234) par celui d'un autre utilisateur pour tester un défaut de contrôle d'accès objet. Les injections (SQL, NoSQL, SSTI) ciblent les champs de filtrage ou de tri souvent moins bien protégés dans les APIs. Les failles d'authentification incluent la réutilisation de tokens JWT sans vérification de signature, l'absence d'expiration ou l'algorithme 'none'. Pour le durcissement, les contre-mesures essentielles sont : appliquer systématiquement une authorization au niveau objet, imposer un rate limiting strict par token et par IP, valider tous les inputs côté serveur, désactiver les endpoints obsolètes et surveiller en continu l'inventaire des APIs exposées avec des outils comme 42Crunch ou Salt Security.