Le rate limiting n'est pas une sécurité
Un quota protège votre backend contre vos clients légitimes. Il ne protège à peu près rien contre un attaquant. Distinguer les deux évite un faux sentiment de protection.
Dans la plupart des ateliers de cadrage, la ligne « protection contre les abus » de la grille de sécurité est cochée par une seule fonctionnalité : le rate limiting. C'est un malentendu, et il est dangereux, parce qu'il donne le sentiment que le sujet est traité.
Ce qu'un quota fait vraiment
Le rate limiting répond à une question de capacité : combien d'appels ce consommateur a-t-il le droit de faire, pour que le backend tienne et que les autres consommateurs ne soient pas affectés ?
C'est une fonction de médiation, pas de sécurité. Elle protège votre plateforme contre son succès : le batch mal configuré d'une équipe interne, le retry en boucle d'un partenaire, le pic de trafic d'un client qui a branché un nouveau canal sans prévenir. Ces cas sont réels, fréquents, et le quota est la bonne réponse.
Ce qu'un quota ne fait pas
Un attaquant ne dépasse pas les quotas. Il travaille en dessous.
- L'énumération de ressources se fait très bien à 10 requêtes par seconde, pendant des heures, en variant les identifiants. Le quota ne voit rien : chaque appel est valide.
- Le credential stuffing se distribue sur des milliers d'adresses IP, chacune loin sous le seuil.
- L'exfiltration par une clé volée ressemble, vue du quota, au trafic normal du client volé.
Ce qui détecte ces comportements, ce n'est pas un seuil de débit, c'est une analyse du contenu et de la forme des appels : taux d'erreurs 404 anormal sur une plage d'identifiants, diversité des paramètres, géographie incohérente avec l'historique du consommateur. Autrement dit, de la détection, pas de la limitation.
La question du périmètre
Le second malentendu porte sur la clé du quota. Un quota par adresse IP est à peu près inutile en 2026 : les consommateurs légitimes sortent de NAT d'entreprise et de plateformes cloud partagées, les attaquants tournent sur des adresses résidentielles louées.
Le quota utile est posé sur l'identité applicative : la clé, le client OAuth, le certificat. Ce qui suppose que chaque consommateur ait une identité propre, et donc que la souscription en libre-service fonctionne. Une plateforme où les équipes se partagent des clés sous le manteau ne peut ni limiter ni détecter proprement : elle voit un seul gros consommateur.
Chaque protection a sa couche
Le troisième malentendu est de tout attendre de la gateway. Les trois familles de protection ne se posent pas au même endroit, et les confondre revient à en payer une pour n'en avoir aucune.
| Ce qu'on veut arrêter | Où cela se pose | Pourquoi pas ailleurs |
|---|---|---|
| Le volume brut, déni de service, robots | En amont : CDN, protection L7, pare-feu applicatif | La gateway qui absorbe le flot tombe avec lui |
| Le dépassement contractuel d'un consommateur | Sur la gateway, par identité | Elle est le seul point qui connaisse la souscription |
| L'épuisement d'une ressource chère | Dans le service, par requête coûteuse | Seul le service sait qu'un rapport coûte mille fois une lecture |
La conséquence pratique est simple : un quota de gateway posé pour arrêter une attaque volumétrique arrive trop tard, puisque le trafic a déjà traversé la terminaison TLS et consommé une connexion.
Régler le quota comme ce qu'il est : de la capacité
Puisque le quota sert la capacité, il se règle sur le trafic légitime, jamais sur une intuition de ce qu'un attaquant ferait.
La méthode tient en quatre pas. Mesurer, sur trente jours, le débit de pointe par consommateur, au centile 99 de fenêtres d'une minute. Poser la limite à deux ou trois fois cette valeur : la marge absorbe une reprise après incident sans laisser passer une boucle.
Choisir ensuite la fenêtre selon ce qu'on protège. La seconde protège le backend d'une rafale, la journée protège un budget, et les deux se posent ensemble parce qu'elles ne traitent pas le même risque. Enfin, fixer une valeur par défaut basse pour tout nouveau consommateur, puisqu'on n'a aucune mesure le concernant.
Deux réglages décident ensuite de la paix sociale. La dérogation doit être une demande traitée en libre-service avec une date d'expiration, sans quoi elle devient une exception permanente que personne ne relit. Et le refus doit être exploitable par le consommateur : un code 429 accompagné d'un délai de reprise, faute de quoi les clients réessaient immédiatement et transforment le quota en amplificateur de charge.
Ce qu'il faut construire à la place
La protection réelle d'une API exposée se joue sur quatre plans, et le quota n'est que le premier :
- Capacité : le quota réglé comme ci-dessus. C'est le rate limiting, à sa juste place.
- Authentification : pas d'opération anonyme sur des données, des identités applicatives individuelles, une rotation qui fonctionne.
- Autorisation : le contrôle d'accès par ressource, celui qui empêche le client A de lire les données du client B en changeant un identifiant dans l'URL. C'est le premier risque du classement OWASP API Security, il se produit à débit normal avec une authentification valide, et aucun quota ne l'adresse.
- Détection : des alertes sur les motifs anormaux, branchées sur les journaux de la gateway, avec quelqu'un qui les reçoit.
L'épreuve simple
Prenez une clé d'API légitime de votre plateforme et essayez, à 5 requêtes par seconde, d'énumérer une ressource qui ne vous appartient pas. Si rien ne vous arrête et que personne n'est alerté, votre « protection contre les abus » est un quota de capacité, et il vaut mieux le savoir avant que quelqu'un d'autre ne le découvre.
C'est un des tests de l'accès qu'on rejoue à chaque audit, et il est rarement concluant du premier coup.
Publié en juin 2025.
Sur le même sujet