Définition
Le rate limiting est un contrôle de gestion de trafic qui impose une borne supérieure à la fréquence à laquelle un client peut effectuer une action particulière dans une fenêtre de temps spécifiée. Quand un client dépasse le seuil, le serveur répond par une erreur — typiquement HTTP 429 Too Many Requests — ou écarte silencieusement les requêtes en excès. La fenêtre se réinitialise soit selon un calendrier fixe (compteur « fenêtre fixe »), soit en glissant (compteur « fenêtre glissante »), les fenêtres glissantes offrant une application plus douce qui empêche l’exploitation en rafale aux frontières de fenêtre.
Le rate limiting est l’un des contrôles de sécurité web les plus anciens et universellement déployés. L’OWASP (Open Web Application Security Project) le recommande comme défense de premier rang contre la force brute, le credential stuffing et l’abus automatisé de formulaires. Cloudflare propose le rate limiting comme fonctionnalité de son WAF, avec des règles configurables par chemin URL, méthode HTTP, IP, valeur de cookie et en-tête de requête. AWS WAF, Azure Front Door et Google Cloud Armor offrent des capacités équivalentes.
Comment fonctionne le rate limiting
Un rate limiter maintient un compteur pour chaque identifiant client unique — le plus souvent l’adresse IP source, mais parfois un identifiant de compte, une clé API ou un cookie de session. Quand une requête arrive, le serveur vérifie la valeur courante du compteur pour cet identifiant. Si elle est sous le seuil, la requête est autorisée et le compteur est incrémenté. Si elle est au seuil ou au-dessus, la requête est rejetée par une réponse 429 ou traitée selon la politique configurée.
Le stockage de compteurs s’implémente typiquement dans Redis ou Memcached pour permettre des recherches rapides et distribuées sur plusieurs instances serveur — exigence pour les applications à mise à l’échelle horizontale. La documentation Cloudflare décrit le rate limiting au niveau du réseau edge, où les règles sont appliquées avant que les requêtes n’atteignent le serveur d’origine, distribuant la réduction de charge sur l’infrastructure mondiale de Cloudflare.
Les paramètres courants dans un contexte de concours incluent :
- Votes par IP par fenêtre temporelle : configuration la plus courante. Exemple : pas plus d’1 vote par IP sur une fenêtre de 24 heures.
- Votes par compte par concours : appliqué au niveau applicatif via l’identifiant de compte authentifié.
- Inscriptions par IP par heure : appliqué au point de création de comptes pour ralentir le farming par bot.
- Appels API par jeton par minute : pertinent pour les plateformes exposant une API de vote publique.
Le rate limiting peut aussi être appliqué de façon probabiliste — par exemple, des limites plus strictes pour les requêtes arrivant avec des signaux comportementaux ou d’empreinte suggérant l’automatisation, et des limites plus souples pour les sessions à indicateurs humains à forte confiance.
Où vous le rencontrez
Le rate limiting est un contrôle omniprésent, présent dans pratiquement toute plateforme web. Les opérateurs de concours le rencontrent le plus directement à trois points : le point de soumission de vote, le formulaire d’inscription, et (si la confirmation par e-mail est requise) le pipeline d’envoi d’e-mails. Les intégrations de concours pilotées par API rencontrent les limites sur les points de terminaison API de la plateforme.
Pour vous, le rate limiting se manifeste le plus visiblement par une erreur HTTP 429 ou un message spécifique à la plateforme tel que « Vous avez déjà voté » ou « Veuillez patienter avant de revoter ». De nombreuses plateformes implémentent un rate limiting souple — acceptant la requête mais écartant silencieusement le doublon — pour ne pas signaler aux fraudeurs potentiels l’existence du contrôle.
La documentation Cloudflare WAF rate limiting note que les règles peuvent d’abord être en mode log seul pendant une phase d’analyse, puis basculées en mode bloquant une fois le seuil approprié calibré. Cette approche en deux phases aide à éviter de bloquer accidentellement des poussées de votes légitimes.
Exemples concrets
Un concours pour blogueurs culinaires en France configure son système de vote avec une limite par IP de 24 heures. Pendant la dernière semaine, vous tentez de soumettre 50 votes successifs depuis la même IP résidentielle. Le premier est accepté ; les 49 suivants reçoivent une réponse 429. Votre navigateur affiche un message expliquant la limitation à un vote par jour.
Une plateforme SaaS de concours hébergeant des centaines de concours simultanés utilise le rate limiting Cloudflare au niveau edge. Un bot ciblant un concours avec 10 000 requêtes par minute est limité à un maximum de 60 requêtes par minute en edge, les requêtes en excès n’atteignant jamais le serveur d’origine. Les journaux d’origine ne montrent que le trafic limité, et l’utilisation CPU côté origine reste inchangée.
Une revue sécurité OWASP du micro-site de concours d’une startup identifie l’absence de rate limiting sur le point de renvoi d’e-mail de confirmation comme une vulnérabilité — un attaquant pourrait inonder la boîte d’une victime en déclenchant des milliers d’e-mails de confirmation. La revue recommande une limite de 3 renvois par adresse e-mail par heure, conforme aux directives OWASP de prévention de force brute.
Concepts liés
La détection d’anomalies est un complément plus sophistiqué au rate limiting : là où le rate limiting impose des seuils durs, la détection d’anomalies identifie les écarts par rapport à un profil comportemental appris, capturant les campagnes qui restent juste sous les limites fixes. La diversité ASN devient pertinente quand des limites par IP sont appliquées et qu’un fraudeur distribue ses requêtes sur de nombreuses IP pour rester sous les seuils — l’analyse au niveau ASN détecte le motif agrégé. reCAPTCHA v3 fournit un score de risque comportemental qui peut être combiné au rate limiting pour appliquer des limites plus strictes sélectivement aux sessions notées comme potentiellement automatisées.
Limites / Mises en garde
Le rate limiting par IP est moins efficace dans les environnements à NAT opérateur, où une seule IP publique peut représenter des centaines d’abonnés mobiles légitimes. Une limite par IP d’1 vote sur 24 heures empêcherait à tort la plupart d’entre eux de voter. C’est pourquoi le rate limiting sur les plateformes de concours doit être combiné à une déduplication par compte ou par cookie quand l’audience mobile est significative. De plus, des limites trop agressives peuvent dégrader l’expérience pour les votants légitimes provenant de réseaux partagés tels que campus universitaires, bureaux d’entreprise ou hotspots Wi-Fi publics importants.
