Rate limiting : protéger une API avant l’incendie

Tu sais ce qui arrive souvent quand une API commence à marcher un peu trop bien. Elle devient victime de son succès. Un petit pic de trafic, un bot mal réglé, un intégrateur qui boucle sur une requête en prod, ou juste un endpoint public qui se fait scanner… et d’un coup, ça chauffe. Très vite.

Le rate limiting, c’est un de ces sujets pas très sexy. Mais c’est littéralement un extincteur posé au mur. Tant que rien ne brûle, personne n’y touche. Le jour où ça flambe, tu es content qu’il soit là.

Pourquoi le rate limiting est souvent oublié (jusqu’au jour où…)

Parce que l’API fonctionne. Parce que « on verra plus tard ». Parce que tu as mis un WAF et ça te rassure un peu.

Sauf que le problème est rarement « un hacker très intelligent ». C’est plutôt :

• un script qui envoie 200 requêtes par seconde sans le vouloir
• un scraping agressif
• un formulaire mobile qui retry en boucle
• un partenaire qui consomme ton API sans cache
• un endpoint de login qui se fait bruteforce

Et au milieu de ça, ta base de données. Ton CPU. Tes threads. Tes quotas cloud. Et tes vrais utilisateurs qui arrivent et se prennent du timeout.

Le rate limiting ne règle pas tout, mais il donne un rythme. Et un plafond.

Ce que le rate limiting protège, concrètement

Quelques bénéfices très terre à terre :

1. stabilité : tu limites les effets de charge brutale
2. équité : un seul client ne mange pas toute la bande passante
3. sécurité : tu ralentis bruteforce et abuse
4. coûts : moins de requêtes inutiles, moins de facture
5. qualité de service : tu peux réserver de la capacité aux clients premium

Et oui, ça aide aussi côté SEO et perf indirecte si ton API alimente ton front.

Les stratégies classiques (et ce qu’elles impliquent)

Il n’existe pas une seule recette, plutôt des approches. Les plus utilisées :

1) Le token bucket (le plus « smooth »)

Tu as un seau de jetons. Chaque requête consomme un jeton. Les jetons se rechargent à un débit constant. Si le seau est vide, tu refuses.

Avantage : ça autorise les petits bursts naturels (genre un chargement de page avec 5 appels API). Et ça reste contrôlé.

2) Le leaky bucket (le plus régulier)

Tu « fais couler » les requêtes à un débit fixe. Si ça arrive trop vite, ça déborde.

Avantage : très stable côté backend. Inconvénient : parfois frustrant côté utilisateur si ça lisse trop.

3) La fenêtre fixe (simple, mais brutale)

Exemple : 100 requêtes par minute. Tu comptes, puis tu remets à zéro à la minute suivante.

Simple à implémenter. Mais l’effet « bord de minute » existe : tu peux faire 100 requêtes à 12:00:59 puis 100 à 12:01:01. Donc en vrai, ça peut taper fort.

4) La fenêtre glissante (plus juste)

Tu regardes les 60 dernières secondes, pas « la minute calendrier ». Plus équitable, plus réaliste, un peu plus coûteux à calculer.

Où appliquer la limite : pas seulement « sur l’API »

Question importante. Parce que limiter au mauvais endroit, ça ne sert à rien.

Tu peux appliquer le rate limiting :

• au niveau du reverse proxy : Nginx, Traefik, HAProxy
• au niveau du gateway : Kong, Tyk, API Gateway AWS, Apigee
• dans l’application : middleware Express, Laravel, Spring, etc.
• au niveau CDN/WAF : Cloudflare, Fastly (pratique pour absorber tôt)

En général, tu veux au moins une barrière « en amont », avant que ça n’atteigne ton app. Et parfois une deuxième barrière logique dans l’app pour des règles métiers.

Les règles qui marchent bien en pratique

Ce n’est pas seulement « X requêtes par minute ». La question c’est : pour qui, et pour quoi.

Quelques axes :

• par IP : basique, utile, mais attention NAT et mobiles
• par clé API : idéal pour partenaires et apps
• par utilisateur : quand tu as auth, plus juste
• par route : login plus strict, lecture plus large, écriture plus serrée
• par combinaison : clé API + route, ou utilisateur + route

Exemples réalistes :

• /login : 5 tentatives par minute par IP
• /search : 30 requêtes par minute par utilisateur
• POST /orders : 10 par minute par utilisateur
• endpoints publics : 60 par minute par IP, avec burst autorisé

Et surtout, tu renvoies le bon statut : 429 Too Many Requests.

Les en-têtes à renvoyer (ça évite beaucoup de tickets support)

Si tu limites, aide le client à comprendre.

Souvent, on utilise :

• Retry-After
• X-RateLimit-Limit
• X-RateLimit-Remaining
• X-RateLimit-Reset

Certaines specs modernes préfèrent des en-têtes standardisés (selon ton stack), mais l’idée reste la même : expliquer quand réessayer.

Et côté message, simple. Pas agressif. Juste clair.

Exemple :

« Vous avez atteint la limite de requêtes. Réessayez dans 20 secondes. »

Stockage et cohérence : le détail qui casse tout

Dès que tu as plusieurs instances (Kubernetes, autoscaling), compter en mémoire locale ne suffit plus.

Il te faut un stockage partagé, typiquement :

• Redis : le grand classique (rapide, TTL, atomicité)
• Memcached : possible, moins riche
• base SQL : rarement une bonne idée pour ça
• solutions gateway : elles gèrent déjà le compteur

Et attention aux opérations atomiques. Si ton incrément n’est pas atomique, tu auras des trous ou des contournements.

Ne pas se tirer une balle dans le pied

Quelques pièges fréquents :

• limiter trop bas et casser des usages normaux
• limiter globalement sans distinguer endpoints lourds et légers
• oublier les « burst » légitimes (chargement initial d’appli)
• bloquer tout un bureau derrière une IP NAT
• renvoyer 403 au lieu de 429 (les clients comprennent mal)
• ne pas monitorer les 429 (alors que c’est une info produit)

Tu veux des métriques : nombre de 429, top IP, top clés API, endpoints les plus limités. Et un petit dashboard. Même minimal.

Un plan simple pour s’y mettre cette semaine

Si tu veux faire ça sans te perdre :

1. mets une limite « large » au niveau proxy ou gateway
2. ajoute une limite plus stricte sur /login et endpoints sensibles
3. renvoie 429 + Retry-After
4. instrumente : logs, métriques, alertes sur explosion de 429
5. ajuste après observation, pas au doigt mouillé

Sur Le Blog Tech Pro de Samyn-Antoy ABASSE ( https://monblog-sa-abasse.blogspot.com ), je partage souvent ce genre de checklists pratiques, celles qu’on veut avoir sous la main quand on déploie à l’arrache et qu’on se dit « mince, on a oublié un truc ». Si tu veux, passe y jeter un oeil et garde le lien dans tes favoris, ça sert plus souvent qu’on croit.

Conclusion : mieux vaut un plafond maintenant qu’une panne plus tard

Le rate limiting, ce n’est pas un luxe. C’est une ceinture de sécurité. Tu peux rouler sans… jusqu’au jour où tu ne peux plus.

Et le truc, c’est que ça ne demande pas forcément une grosse refonte. Une bonne règle au bon endroit, avec des 429 propres et un compteur partagé, et tu viens déjà d’éviter pas mal d’incendies.

Questions fréquemment posées

Qu'est-ce que le rate limiting et pourquoi est-il essentiel pour une API ?

Le rate limiting est une technique qui limite le nombre de requêtes qu'un client peut envoyer à une API sur une période donnée. Il est essentiel pour protéger l'API contre les pics de trafic, les abus comme le scraping agressif ou le bruteforce, et pour garantir la stabilité, l'équité et la qualité de service aux utilisateurs.

Pourquoi le rate limiting est-il souvent négligé jusqu'à ce qu'il y ait un problème ?

Le rate limiting est souvent oublié car l'API fonctionne bien au départ, on préfère remettre sa mise en place à plus tard, ou on se repose sur un WAF. Pourtant, les problèmes viennent rarement d'attaques sophistiquées, mais plutôt de scripts mal configurés, de partenaires sans cache ou de formulaires qui réessayent en boucle, ce qui peut rapidement saturer les ressources.

Quelles sont les principales stratégies de rate limiting utilisées ?

Les stratégies classiques incluent : 1) Le token bucket, qui permet des petits pics naturels tout en contrôlant le débit ; 2) Leaky bucket, qui régule un débit fixe et stable ; 3) La fenêtre fixe, simple mais pouvant causer des pics à la limite des intervalles ; 4) La fenêtre glissante, plus équitable et réaliste en analysant les requêtes sur une période glissante.

Quels sont les bénéfices concrets du rate limiting pour une API ?

Le rate limiting apporte plusieurs avantages : il assure la stabilité du système en limitant les charges brusques, garantit l'équité entre clients en évitant qu'un seul monopolise la bande passante, améliore la sécurité en ralentissant les attaques par bruteforce ou abus, réduit les coûts liés aux requêtes inutiles et permet d'offrir une meilleure qualité de service notamment aux clients premium.

À quels niveaux peut-on appliquer le rate limiting dans l'infrastructure d'une API ?

Le rate limiting peut être appliqué à différents niveaux : au niveau du reverse proxy (Nginx, Traefik), au niveau du gateway API (Kong, Tyk), directement dans l'application via des middlewares (Express, Laravel), ou encore au niveau CDN/WAF (Cloudflare). Idéalement, on met au moins une barrière en amont pour limiter la charge avant que cela n'atteigne l'application.

Quelles règles de limitation sont efficaces en pratique pour gérer le trafic API ?

Les règles efficaces ne se limitent pas à un simple quota global. Elles doivent être adaptées selon : par IP (utile mais attention aux NAT et mobiles), par clé API (idéal pour partenaires), par type d'opération (login versus lecture), ou par utilisateur. Cela permet d'ajuster finement la limitation selon le profil et les besoins réels.