Que sont les attaques d'API ?
Les attaques d'API détournent une API pour voler des données ou perturber un service. Risques de l'OWASP API Security Top 10 (2023) et défenses.
Que sont les attaques d'API ?
Les attaques d'API sont des tentatives de détourner une interface de programmation pour lire des données que l'appelant ne devrait pas voir, modifier des données qu'il ne devrait pas toucher, ou épuiser le service pour que les vrais utilisateurs ne puissent plus s'en servir. Elles visent directement les endpoints derrière les applications web et mobiles : une faille que le front end masque reste atteignable par une simple requête HTTP. Les comprendre est la première étape de la sécurité des API. Cette page est un éclairage défensif.
Pourquoi les attaquants visent les API
- Accès direct aux données : les réponses sont structurées et viennent souvent directement de la base.
- Forme prévisible : des routes documentées et des identifiants séquentiels sont faciles à automatiser.
- Nombreux points d'entrée : API publiques, partenaires et internes multiplient la surface, et les oubliées subsistent (voir découverte d'API).
- Pas de navigateur entre les deux : les bots appellent les endpoints sans CAPTCHA ni page visible.
L'OWASP API Security Top 10 (2023)
La référence est l'OWASP API Security Top 10, édition 2023. Ses dix risques (intitulés d'origine) et l'idée défensive de chacun :
| Risque | Ce qui dysfonctionne | Défense principale |
|---|---|---|
| API1:2023 Broken Object Level Authorization | Un endpoint renvoie un objet par ID sans vérifier que l'appelant y a droit | Vérifier la propriété à chaque accès à un objet |
| API2:2023 Broken Authentication | Une connexion, un jeton ou des identifiants mal gérés permettent d'usurper un utilisateur | Validation stricte des jetons, connexion limitée en tentatives, MFA |
| API3:2023 Broken Object Property Level Authorization | Des champs interdits sont lus ou écrits, y compris par des réponses trop bavardes | Schémas de réponse explicites, liste blanche des champs modifiables |
| API4:2023 Unrestricted Resource Consumption | Les requêtes consomment CPU, mémoire, bande passante ou services payants | Limites de débit, quotas, plafonds de taille et de pagination |
| API5:2023 Broken Function Level Authorization | Des utilisateurs ordinaires atteignent des fonctions d'administration | Refus par défaut, contrôle du rôle par fonction |
| API6:2023 Unrestricted Access to Sensitive Business Flows | L'automatisation détourne un parcours légitime, comme des achats ou inscriptions en masse | Limites par parcours et détection des bots |
| API7:2023 Server Side Request Forgery | L'API appelle une URL fournie par l'attaquant et atteint des ressources internes | Listes blanches de destinations sortantes, validation des URL |
| API8:2023 Security Misconfiguration | Durcissement absent, erreurs bavardes, CORS ouvert, fonctions inutiles | Configuration durcie et reproductible, revue régulière |
| API9:2023 Improper Inventory Management | Anciennes versions et endpoints non documentés restent exposés | Tenir un inventaire, retirer les anciennes versions |
| API10:2023 Unsafe Consumption of APIs | Votre service fait trop confiance aux données d'API tierces | Valider les données reçues, fixer des timeouts |
Pour une présentation claire des principaux, voir principaux risques de sécurité des API.
Un exemple concret
Prenons BOLA (API1). Un utilisateur connecté ouvre /api/orders/1001 et voit sa propre commande. Si le serveur vérifie seulement qu'il est connecté, passer à 1002 peut renvoyer la commande de quelqu'un d'autre. Un script teste des milliers d'ID en quelques minutes. La solution n'est pas de cacher les ID mais de vérifier, à chaque requête, que cet appelant possède cette commande.
Erreurs courantes en défense
- Compter sur le front end. Masquer un bouton ne protège pas l'endpoint derrière.
- Authentification sans autorisation. Savoir qui est quelqu'un ne dit pas ce qu'il peut toucher.
- La limitation de débit comme seul contrôle. Elle freine l'abus (abus d'API) mais ne protège pas de BOLA ni de l'injection.
- Versions oubliées. Un ancien
/v1sans les nouveaux contrôles est une porte d'entrée fréquente. - Faire confiance aux API partenaires. Traitez leurs réponses comme une entrée non fiable.
Détecter et réduire les attaques
Superposez les contrôles : authentifier et autoriser chaque requête au niveau objet et fonction, valider l'entrée avec un schéma, ne renvoyer que les champs nécessaires, limiter débit et tailles par client, tenir un inventaire des endpoints et versions, et journaliser assez pour enquêter. Méritent une alerte : des rafales de 401 et 403, un client qui parcourt des ID séquentiels, des pics soudains d'erreurs ou de latence. Pour les inondations, voir comment stopper les attaques DDoS et le guide de la limitation de débit des API.
Où s'intègrent supervision et tests de charge
LoadFocus n'est pas un scanner de sécurité et ne détecte pas des failles comme l'injection ou BOLA. Il aide côté disponibilité. La supervision d'API vérifie les endpoints à intervalle régulier (les contrôles gratuits tournent toutes les 5 minutes) et alerte quand codes de statut, réponses ou temps de réponse dérivent, ce qui peut être un signe précoce qu'on sollicite l'API. Les tests de charge montrent le comportement de votre propre API sous fort trafic concurrent, pour vérifier que les limites de débit s'activent et que le service se dégrade proprement. Ne testez que des systèmes qui vous appartiennent ou pour lesquels vous avez une autorisation.
Questions fréquentes : attaques d'API
Quelle est l'attaque d'API la plus courante ?
L'OWASP place Broken Object Level Authorization en API1:2023, premier risque de son Top 10, et elle est très répandue car elle apparaît dès qu'un endpoint fait confiance à un ID sans vérifier la propriété.
En quoi diffèrent-elles des attaques sur les applications web ?
Elles visent des endpoints de machine à machine qui renvoient des données structurées, sans page ni CAPTCHA. Les failles d'autorisation et de validation sont donc plus faciles à trouver et à automatiser.
Un WAF ou un limiteur de débit peut-il les arrêter ?
Ils aident contre les inondations, les charges connues et la force brute, mais pas contre les failles de logique comme BOLA ou l'abus de parcours métier. Ils sont plus efficaces avec des contrôles d'autorisation et une validation des entrées.
Comment savoir si mon API est attaquée ?
Comparez à une base de référence : trafic soudain de certains clients, hausse des 401 ou 403, parcours d'ID séquentiels, pics de latence. Une supervision continue avec alertes les rend visibles vite.
Un test de charge détecte-t-il des failles de sécurité ?
Non. Il mesure la performance et la stabilité sous trafic. Il peut confirmer que limites de débit et capacité tiennent, mais il faut un audit de sécurité ou un scanner pour trouver des vulnérabilités.
Outils LoadFocus connexes
Mettez ce concept en pratique avec LoadFocus, la plateforme même qui propulse tout ce que vous venez de lire.