Comprendre la limitation de débit : protéger les API sans ralentir les clients

La limitation de débit est l’un des moyens les plus simples de protéger une API, un flux de connexion ou une action web coûteuse. C’est aussi facile à mal configurer. Une limite trop souple laisse un endpoint exposé à la force brute, au scraping, au déni de service ou à des coûts fournisseurs imprévus. Une limite trop stricte transforme les réseaux de bureaux partagés, les opérateurs mobiles et les pics légitimes en erreurs visibles par les clients.

La bonne question n’est pas « Combien de requêtes une adresse IP peut-elle effectuer ? », mais quel acteur peut effectuer quelle opération, à quel coût, sur quelle période, et que doit-il se passer lorsque le budget est épuisé ? Ce guide explique comment y répondre sans lier la conception à un fournisseur de périphérie précis.

Ce que protège la limitation de débit

Le modèle de menace doit couvrir davantage que les attaques volumétriques. OWASP classe la consommation non restreinte de ressources comme un risque de sécurité des API, car chaque requête peut consommer de la bande passante, du CPU, de la mémoire, du stockage ou des services aval facturés. Une attaque de faible volume contre une opération coûteuse de recherche, d’export, de messagerie ou de réinitialisation de mot de passe peut être plus dommageable qu’un grand nombre de consultations bon marché servies depuis le cache.

Distinguez les résultats que vous voulez empêcher :

• Abus d’authentification : force brute, credential stuffing et saturation des réinitialisations de mot de passe.
• Épuisement des ressources : trop d’appels simultanés ou coûteux.
• Abus métier : vérifications de stock, tentatives de coupons, création de comptes ou envoi de messages.
• Problèmes d’équité : un client consomme un quota partagé et prive les autres.
• Inflation des coûts : appels répétés vers du stockage, des e-mails, des SMS, de l’IA ou des API partenaires facturés à l’usage.

Choisissez la bonne clé de limitation

Une règle fondée uniquement sur l’IP constitue une première ligne utile, mais pas une politique complète. Les adresses partagées génèrent des faux positifs, tandis que les attaquants distribués peuvent faire tourner les adresses. Utilisez des compteurs séparés lorsque l’application peut identifier l’acteur de manière sûre :

• IP ou réseau : contient les floods anonymes et protège la périphérie elle-même.
• Utilisateur ou compte authentifié : protège un compte contre une attaque distribuée.
• Clé API ou client OAuth : donne à une intégration connue un budget prévisible.
• Signal de session ou d’appareil : aide à contenir les flux non authentifiés sans reposer sur une seule adresse.
• Route et méthode : distingue un GET peu coûteux d’un POST, export ou recherche coûteux.
• Ressource ou objet métier : protège un compte, SKU, boîte aux lettres ou réservation.
• Budget de service agrégé : protège l’origine et les dépendances facturées pour l’ensemble des appelants.

Utilisez plus d’une clé lorsque la menace le justifie. Par exemple, un endpoint de connexion peut avoir un budget source pour empêcher un réseau d’essayer de nombreux comptes et un budget compte pour empêcher de nombreux réseaux de cibler un même nom d’utilisateur. Ne révélez pas le compartiment interne exact qui s’est déclenché dans une réponse d’erreur.

Choisissez un algorithme et une réponse

Une fenêtre fixe est facile à comprendre, mais peut autoriser un pic à la frontière entre deux fenêtres. Une fenêtre glissante mesure l’historique récent de manière plus fluide. Un token bucket autorise des pics contrôlés tout en imposant un débit moyen, ce qui est souvent mieux adapté aux API connaissant de courts pics normaux. Un leaky bucket se vide à un débit constant et peut être utile lorsque le lissage compte davantage que la capacité de pic.

L’algorithme est moins important qu’une application cohérente et distribuée. Si plusieurs nœuds de périphérie ou instances applicatives comptent indépendamment, la limite réelle peut être bien supérieure à celle prévue. Utilisez un compteur partagé à faible latence ou une couche d’application conçue pour un état distribué, et définissez ce qui se produit lorsque cet état est indisponible. Échouer en mode ouvert peut préserver la disponibilité mais accroître les abus ; échouer en mode fermé peut protéger l’origine mais interrompre les clients. Décidez-le par route et documentez-le.

Lorsqu’un client dépasse une limite, renvoyez 429 Too Many Requests lorsqu’une réponse est appropriée. La RFC 6585 définit le code 429 pour la limitation de débit et autorise un en-tête Retry-After. Utilisez-le lorsque le client peut réessayer sans risque après un délai connu. Gardez une réponse générique, évitez de révéler les détails internes du compartiment et assurez-vous que la réponse n’est pas stockée par un cache. En cas de flood sévère, abandonner les connexions ou utiliser une mitigation en amont peut consommer moins de ressources que de générer une réponse pour chaque requête.

Concevez les limites à partir de données probantes

Commencez par un inventaire des routes et classez chacune selon son exigence d’authentification, son trafic normal, son coût de calcul, son coût aval et son impact métier. Mesurez le trafic légitime sur des périodes représentatives qui incluent les mises en production, campagnes, pics régionaux, clients mobiles et tâches partenaires. Observez les pics et la concurrence, pas uniquement les moyennes.

Définissez une limite provisoire avec une justification documentée. Pour les lectures publiques, un budget anonyme partagé peut suffire. Pour les API authentifiées, les quotas par client et les limites spécifiques aux routes sont généralement plus utiles. Pour les actions sensibles, combinez un budget normal généreux avec un budget d’échec plus strict et un contrôle renforcé. Ne copiez jamais un chiffre d’une autre API sans comprendre sa charge de travail et sa population de clients.

Documentez le contrat à destination des développeurs. Indiquez si les quotas sont par minute, par seconde, glissants ou mensuels ; si les appels échoués comptent ; si les nouvelles tentatives sont sûres ; et comment les clients doivent répondre à 429. Les opérations idempotentes doivent utiliser un backoff exponentiel borné avec gigue. Les opérations non idempotentes ont besoin d’une stratégie d’idempotence afin qu’une nouvelle tentative ne duplique pas un paiement ou une commande.

Déployez en toute sécurité

Déployez d’abord une politique en mode journalisation seule ou shadow. Enregistrez la décision proposée, la clé, la route, la catégorie de client, le statut, la latence et le résultat aval sans l’appliquer. Excluez les secrets et évitez de stocker plus de données personnelles que l’investigation ne l’exige.

Appliquez le contrôle canari sur une route ou un faible pourcentage du trafic. Surveillez :

• Les réponses 429 par route, client, région et version de client.
• Les taux de réussite de connexion, paiement, commande et finalisation des appels API.
• Le volume de nouvelles tentatives et l’amplification des requêtes après l’atteinte d’une limite.
• Le CPU de l’origine, la mémoire, le nombre de connexions, la profondeur de file et l’usage des dépendances.
• Les contacts au support et les rapports d’erreur des partenaires.

Conservez une procédure break-glass testée et auditée pour un partenaire identifié ou un intervenant d’incident. N’en faites pas un en-tête secret que n’importe qui peut ajouter. Réévaluez les limites après chaque modification importante de l’application ou du comportement des clients.

Erreurs qui pénalisent les clients

• Utiliser un seuil IP global unique pour chaque route et type d’utilisateur.
• Compter les nouvelles tentatives et les requêtes en échec de manière incohérente entre les couches de périphérie et applicative.
• Faire confiance à un en-tête d’identité fourni par le client sans valider le proxy qui le définit.
• Renvoyer 403 pour chaque événement de limite, ce qui masque la sémantique de nouvelle tentative aux clients.
• Définir Retry-After si bas que les clients créent une tempête de nouvelles tentatives synchronisées.
• Appliquer des limites avant l’observation, sans base de référence pour les pics légitimes.
• Oublier les WebSockets, requêtes GraphQL, uploads de fichiers, tâches d’arrière-plan ou appels internes de service à service.

La limitation de débit fonctionne mieux comme une couche de protection des API, aux côtés de la gestion des bots et d’un WAF. Pour aller plus loin, lisez Protection des API à la périphérie et Comment masquer et protéger votre serveur d’origine.

Références faisant autorité

• RFC 6585: Additional HTTP Status Codes
• OWASP API Security Top 10: API4 Unrestricted Resource Consumption
• NIST SP 800-63B: Throttling authentication attempts

Il n’existe que deux problèmes difficiles en informatique : l’invalidation du cache et le choix des noms.