Qu'est-ce que l'abus d'API ?

Qu'est-ce que l'abus d'API ?

L'abus d'API est l'usage d'une API qui fonctionne d'une manière que son propriétaire n'avait pas voulue : scraping, credential stuffing, achats pilotés par des bots ou simple volume. Rien n'est cassé. Chaque requête peut porter un jeton valide et recevoir un 200 OK. Le problème est de savoir qui appelle, à quelle fréquence et pourquoi, et cela n'apparaît que dans l'ensemble de nombreuses requêtes, de comptes ou d'adresses IP.

L'OWASP traite le volet métier sous le nom API6:2023 Unrestricted Access to Sensitive Business Flows.

Abus d'API, attaques et vulnérabilités

Une vulnérabilité est un défaut de l'API, comme un contrôle d'autorisation absent. Une attaque d'API exploite un tel défaut pour casser le système. L'abus est différent : l'abuseur suit le contrat documenté, mais à une échelle ou avec une intention que l'entreprise n'a jamais voulues. La défense contre les défauts relève de la sécurité des API. La défense contre l'abus porte sur le comportement et le volume, pas sur la correction du code, même si les abuseurs cherchent souvent aussi des failles.

Types courants d'abus d'API

• Scraping : des clients automatisés aspirent de grands volumes de prix, d'annonces ou de profils via des endpoints publics ou authentifiés.
• Credential stuffing : des bots rejouent contre un endpoint de connexion des paires identifiant et mot de passe volées ailleurs. Même avec un faible taux de réussite, ce volume produit des comptes compromis.
• Automatisation par bots : des scripts créent de faux comptes, publient du spam ou réclament des promotions bien plus vite qu'une personne.
• Contournement des limites : rotation d'adresses IP, de clés d'API ou de comptes pour rester sous les limites par client.
• Abus de la logique métier : un flux est utilisé comme prévu, mais pour un résultat non voulu. Parmi les exemples de l'OWASP : acheter la majeure partie d'un produit en stock limité pour le revendre, ou automatiser de fausses inscriptions pour toucher un crédit de parrainage.
• Fraude sur les paiements et la fidélité : test de cartes via un endpoint de paiement, ou devinette de numéros de cartes cadeaux.
• Denial of wallet : saturer un endpoint payant ou coûteux pour faire grossir la facture du fournisseur, sans faire tomber le service.

Un exemple : l'endpoint de SMS payant

Un endpoint de réinitialisation de mot de passe envoie un SMS via un fournisseur qui facture chaque message. Un script l'appelle en boucle avec des numéros de téléphone différents. Chaque appel renvoie un 200 normal, la latence semble correcte et aucune erreur n'est journalisée, mais la facture de SMS grimpe. L'OWASP utilise ce scénario pour API4:2023 Unrestricted Resource Consumption. La parade est une limite par numéro de téléphone et par client sur cet endpoint, plus un plafond de dépenses ou une alerte de facturation chez le fournisseur.

Comment détecter l'abus d'API

Chaque requête isolée paraît légitime, la détection compare donc le comportement à une référence.

• Volume et vitesse : requêtes par compte, clé et IP dans le temps, et nombreux comptes partageant la même empreinte d'appareil.
• Comportement : les personnes font des pauses et varient. Les bots affichent un rythme de machine et des séquences identiques.
• Composition du trafic : un endpoint de connexion ou de réinitialisation avec plusieurs fois son volume habituel, ou un changement brusque de géographie ou de user agent.
• Surveillance : la surveillance d'API conserve l'historique du temps de réponse et des erreurs, si bien qu'un ralentissement progressif se voit sur les graphiques. La surveillance d'API LoadFocus vérifie le code de statut, le corps de la réponse, les en-têtes et le temps de réponse (contrôles gratuits toutes les 5 minutes). Elle ne détecte ni ne bloque l'abus elle-même, associez-la donc aux logs et à un WAF ou un outil antibot.

Comment prévenir l'abus d'API

• Authentification solide : jetons de courte durée, authentification multifacteur à la connexion et gestion soigneuse des clés d'API, faciles à partager et à récolter.
• Limites de débit et quotas : par utilisateur, par clé et par IP, conçus pour que la rotation de l'un d'eux ne remette pas tout à zéro. Le comportement attendu d'un client face à un 429 est expliqué dans éviter le rate limiting des API.
• Gestion des bots : empreintes d'appareil, défis de détection humaine et score de réputation. L'OWASP cite l'empreinte d'appareil, le CAPTCHA et la détection d'actions plus rapides que ce qu'un humain pourrait faire. N'appliquez de la friction qu'aux sessions suspectes.
• Limites sur les flux métier : plafonds d'achat par compte, limites de vitesse sur les récompenses et le paiement.
• Plafonds de dépenses : plafonds ou alertes de facturation pour chaque intégration payante tierce.
• Tester les limites sous charge : une limite n'est prouvée que lorsque des requêtes l'atteignent vraiment. Un test de charge cloud montre si le throttling se déclenche au débit voulu et si l'API se dégrade proprement lors d'une rafale.

Erreurs fréquentes

• Limiter seulement par IP. Les abuseurs répartissent les requêtes sur de nombreuses adresses. Combinez avec des limites par compte et par clé.
• Protéger la connexion mais pas ses voisines. La réinitialisation de mot de passe, l'OTP et l'inscription sont tout aussi souvent abusés.
• Prendre un 200 pour un signe de santé. Un déluge d'appels d'apparence valide ressemble à un succès sur un tableau de statuts.
• Défier tout le monde. Un CAPTCHA à chaque requête pénalise les vrais utilisateurs. Réservez-le au trafic suspect.
• Ne jamais tester les limites. Une règle jamais atteinte sous charge reste une hypothèse.

Questions fréquentes sur l'abus d'API

L'abus d'API est-il la même chose qu'une attaque d'API ?

Non. Une attaque d'API exploite un défaut pour casser le système. L'abus d'API détourne des fonctions qui marchent comme prévu, par automatisation, identifiants volés ou volume excessif, pour extraire une valeur que l'entreprise n'a jamais voulu céder.

En quoi l'abus d'API diffère-t-il d'une attaque DDoS ?

Un DDoS cherche à mettre un service hors ligne. L'abus d'API veut généralement que le service reste debout pour continuer à extraire de la valeur, et il est souvent lent et discret pour rester sous les seuils de détection. Pour les attaques par inondation, voyez comment arrêter les attaques DDoS.

Le rate limiting suffit-il à arrêter l'abus d'API ?

Non. Les abuseurs font tourner adresses IP, clés et comptes pour rester sous les limites par client. Le rate limiting est une couche, à côté de l'authentification, de la gestion des bots, de l'analyse comportementale et des limites sur les flux métier.

Qu'est-ce que le denial of wallet ?

Un abus qui vise le coût plutôt que la disponibilité. Sur des API facturées à l'usage, un attaquant déclenche des opérations payantes ou coûteuses, comme des SMS ou des appels de calcul, pour que la facture du fournisseur grossisse pendant que le service reste en ligne.

Comment LoadFocus aide-t-il face à l'abus d'API ?

LoadFocus ne bloque pas l'abus. La surveillance d'API conserve l'historique du temps de réponse et du statut pour que les ralentissements se remarquent, et les tests de charge avec k6 ou JMeter permettent de vérifier que vos limites de débit et votre throttling tiennent sous fort trafic.