Rate limiting : stopper les abus sans bloquer vos clients

Ce qu'il fait réellement

Chaque visiteur émet des requêtes. Une limite de débit dit : d'un même client, j'accepte tant de requêtes en tant de secondes, et tout ce qui dépasse est refusé. C'est toute l'idée — un compteur assorti d'une conséquence.

Ce qui en fait la valeur, c'est l'asymétrie. Un scraper, un script de credential stuffing ou une intégration devenue folle ressemblent tous à un navigateur au niveau d'une requête isolée ; vous ne pouvez pas les distinguer en en inspectant une seule. Mais leur comportement dans le temps est totalement différent : un humain lit une page et clique sur quelques liens par minute, là où un script en fait des centaines. Le rate limiting attrape un comportement plutôt qu'un contenu, et c'est pour cela qu'il arrête des attaques qu'aucune signature ne reconnaîtrait.

Choisir un chiffre qui ne fait pas de mal

L'erreur consiste à choisir une limite à l'intuition. Partez de ce que fait déjà votre trafic réel : observez votre visiteur légitime le plus actif sur une heure normale, puis placez la limite confortablement au-dessus. Une limite que seul un bot peut atteindre fait son travail sans qu'on la voie ; une limite qu'un client enthousiaste peut déclencher, c'est un ticket de support que vous vous êtes créé vous-même.

Deux détails vous épargnent la plupart des faux positifs. D'abord, souvenez-vous que plusieurs personnes peuvent partager une même adresse — un bureau, une école, le NAT d'un opérateur mobile — donc une limite calibrée pour « un humain » punira tout un immeuble. Ensuite, souvenez-vous de votre propre trafic : la supervision, les health checks, l'intégration d'un partenaire et votre CI proviennent tous de quelques adresses à haute fréquence, et ce sont les premiers clients légitimes qu'une nouvelle limite a tendance à casser.

Commencez délibérément large. Une limite que vous resserrez après une semaine d'observation coûte bien moins cher qu'une limite que vous devez desserrer après la plainte d'un client.

Tous les chemins ne méritent pas la même limite

Un chiffre unique pour tout le site est un compromis qui ne satisfait personne — assez large pour la navigation signifie inutile sur un formulaire de connexion, assez serré pour la connexion signifie une page produit cassée.

Raisonnez en termes de ce qu'une requête vous coûte et de ce que son abus rapporte à l'attaquant. Les endpoints de connexion, de réinitialisation de mot de passe et de paiement sont peu coûteux à appeler et intéressants à attaquer : ils prennent donc les limites les plus strictes — une personne se connecte une fois, pas quarante fois par minute. Les endpoints de recherche et d'API sont coûteux à servir et attirants à scraper : limitez-les selon ce dont une vraie intégration a besoin. Les pages ordinaires et les fichiers statiques sont peu coûteux et très utilisés par de vraies personnes : ils demandent donc des limites généreuses, voire aucune, puisque le cache du CDN les absorbe déjà.

Sur cdn.com.tr, la limite de débit des requêtes se règle au niveau du compte et aussi par règle de diffusion, ce qui rend tout cela praticable : une règle stricte sur votre chemin de connexion, une règle plus souple pour le reste du site.

Pourquoi la périphérie est le bon endroit

Le rate limiting à l'intérieur de votre application fonctionne, au sens où le code s'exécute. Mais quand votre application est en mesure de compter une requête, elle a déjà accepté la connexion, occupé un worker et probablement touché la base de données — l'attaque vous a déjà coûté la ressource que vous cherchiez à protéger. Sous un déluge, le limiteur lui-même fait partie de ce qui s'effondre.

Appliqué à la périphérie, le refus se produit près du client, avant que le trafic n'atteigne votre origine. Votre serveur ne le voit jamais, donc le coût n'est pas pour vous. C'est aussi pour cela que le rate limiting en périphérie continue de fonctionner quand votre origine est déjà en difficulté : la limite n'entre pas en concurrence avec les ressources qu'elle défend.

Rate limiting, WAF et protection DDoS

Ces trois termes sont employés indifféremment alors qu'ils recouvrent des rôles réellement distincts.

Le rate limiting compte. Il sait à quelle fréquence un client demande, et rien de ce qu'il demande. Il arrête la force brute, le scraping et le martèlement accidentel.

Un WAF inspecte. Il lit la requête et bloque celles qui ressemblent à une injection SQL, à du cross-site scripting ou à un exploit connu — une seule requête malveillante est attrapée dès sa première tentative, quelle que soit sa lenteur d'arrivée.

La protection DDoS absorbe. Quand le trafic est assez volumineux pour que le simple fait de le compter vous submerge, il faut encaisser ce volume avec une capacité réseau répartie sur de nombreuses localisations.

Vous avez besoin des trois parce que chacun couvre l'angle mort des autres : une requête astucieuse qu'un compteur laisserait passer, mille requêtes d'apparence innocente dans lesquelles un WAF ne voit rien d'anormal, et un million de requêtes qu'aucune machine seule ne peut même évaluer. Sur cdn.com.tr, ils font partie de la même périphérie et se configurent depuis un seul panneau.

Déployer la limite sans rien casser

Placez la limite assez haut pour vous attendre à ce qu'elle ne se déclenche jamais, puis observez. Regardez ce qui a effectivement été refusé : s'il s'agit d'un scraper ou d'un script de connexion, resserrez en confiance ; s'il s'agit de votre propre supervision ou de l'intégration d'un client, vous venez d'apprendre quelque chose avant que cela ne vous coûte une réclamation.

Gardez des exceptions honnêtes et peu nombreuses — votre supervision et les intégrations partenaires connues, pas « celui qui s'est plaint le plus fort ». Et traitez une limite comme un chiffre vivant : le trafic croît, une application mobile sort, une intégration double sa fréquence d'interrogation. Une limite généreuse l'an dernier peut devenir en silence la raison pour laquelle une fonctionnalité semble cassée.