Limiter une seule IP ne suffit plus à stopper les abus modernes.
La limitation de débit traditionnelle est généralement appliquée comme un nombre de requêtes par adresse IP. Ce modèle est simple, mais le NAT, les réseaux opérateurs, les points de sortie partagés et les passerelles anonymes peuvent placer des utilisateurs légitimes et des sources d'abus dans le même panier. Un trafic élevé depuis une seule IP n'est pas toujours une attaque ; de même, un trafic distribué à faible volume n'est pas toujours innocent.
Le comportement applicatif n'est pas uniforme. Une courte rafale de requêtes d'assets lors du chargement d'une page est normale, mais le même taux sur un endpoint de paiement, de connexion ou d'API peut signaler un abus. Un modèle plat de "N requêtes par minute" peut à la fois nuire à l'expérience utilisateur et manquer de vraies attaques.
Le credential stuffing, l'énumération de comptes et les patterns de bots ne peuvent pas être lus à partir des seuls comptages bruts de requêtes. Un grand nombre de tentatives de connexion échouées sur un endpoint d'authentification peut sembler faible dans le trafic total. Des compteurs non corrélés au nom d'utilisateur, à la session, à la clé API, au header personnalisé ou au comportement de réponse perdent leur contexte de sécurité.
La protection des ressources est un problème distinct. Même lorsque des clients distribués envoient des requêtes à un faible taux par client, la charge agrégée peut épuiser le pool de connexions d'un backend, son infrastructure de recherche ou sa capacité de téléchargement de fichiers. La limitation de débit est nécessaire non seulement pour stopper un attaquant, mais pour distribuer la capacité du backend de manière équitable et contrôlée.
L'approche de TR7 fait passer la limitation de débit d'un seuil grossier basé sur l'IP à une politique de sécurité contrôlée applicable selon les dimensions utilisateur, endpoint, session, clé API, clé composite et bande passante.
Notre approche
TR7 implémente la limitation de débit comme un contrôle WAAP multidimensionnel conçu autour du périmètre, du modèle de compteur et de la sélection d'action fonctionnant ensemble.
Le modèle à fenêtre glissante suit le comportement réel du trafic
TR7 suit les taux de requêtes, de connexions, d'erreurs et de bande passante dans une fenêtre temporelle configurable. Des durées de fenêtre différentes permettent d'évaluer indépendamment les pics de courte durée et la charge élevée soutenue.
La clé de limite est choisie en fonction de la classe d'attaque
Différents périmètres peuvent être créés en utilisant l'IP, l'IP et le user agent, le nom d'utilisateur, la clé API, le cookie, le header ou des clés composites. Cela permet de détecter les abus plus précisément sans pénaliser les utilisateurs légitimes derrière la même IP.
Le modèle d'action est appliqué progressivement selon la gravité
Une politique peut refuser la requête, appliquer un blocage temporaire, rediriger vers une vérification CAPTCHA ou imposer un plafond de bande passante. Chaque violation n'est pas traitée avec le même niveau de réponse.
L'architecture de compteur in-process maintient une latence faible
Les compteurs sont maintenus dans le chemin des données — aucun appel à une base de données externe n'est nécessaire au moment de la décision. Les déploiements multi-instances sont pris en charge via la synchronisation des compteurs, permettant une application cohérente des politiques dans les configurations distribuées.
Capacités
TR7 Rate Limiting couvre différents scénarios d'abus — des politiques de bots préconfigurées aux clés composites personnalisées — via un modèle de gestion unique.
Les profils de limitation de débit intégrés fournissent un point de départ prêt pour la production
TR7 est livré avec des politiques préconfigurées pour les scénarios courants de bots et d'abus. Le profil `bot_rateLimit` peut retourner HTTP 429 à 300 requêtes par minute par IP. `bot_rateLimitStrict` peut appliquer un blocage temporaire de 5 minutes après 100 requêtes par minute. `bot_rateLimitCaptcha` peut rediriger vers un flux CAPTCHA auto-hébergé après 150 requêtes par minute.
Une limite souple et un plafond dur — la réponse est une montée, pas une falaise
Chaque protection porte deux seuils. Franchir la limite souple déclenche une réponse mesurée — ralentir, challenger, lisser — et seul le plafond dur jette du trafic. Le mode observation rapporte les deux séparément : les seuils se fixent sur ce que votre trafic a réellement fait, pas sur un chiffre estimé. Un seuil unique impose chaque fois le même choix : laisser passer l'attaque, ou jeter vos clients avec elle.
Les types de déclencheurs séparent les requêtes brutes, les échecs de connexion et le score de risque
Le type `requests` suit le taux brut de requêtes. `failedAuthAttempts` gère les tentatives d'authentification échouées avec un compteur dédié. `riskScore` peut prendre des décisions basées sur un score de bot ou comportemental. `static` est utilisé pour des contrôles inconditionnels tels que le CAPTCHA obligatoire sur un flux spécifique.
Les périmètres IP, utilisateur et clé composite peuvent être utilisés ensemble
Le périmètre `global` surveille la charge agrégée sur l'ensemble d'un service. Les périmètres `ip`, `ip+ua`, `username` et `composite` créent des limites plus ciblées. La structure composite peut combiner un header personnalisé, un cookie, une clé API ou un champ du corps de la requête pour produire une clé de compteur personnalisée. Cette flexibilité permet aux applications B2B API et multi-locataires de refléter plus précisément les limites d'utilisation réelles.
La même requête peut être évaluée simultanément par plusieurs politiques de débit
Un pool de services peut avoir plusieurs politiques de limitation de débit actives en même temps. Par exemple, la même requête peut être soumise à la fois à un plafond DDoS à périmètre IP et à une limite d'utilisation équitable à périmètre utilisateur. Chaque politique suit son propre compteur indépendant. Cette structure permet un modèle de protection en couches plutôt qu'un seul seuil.
L'action de blocage temporaire maintient la clé bloquée même après la baisse du taux
Lorsque l'action `block` se déclenche, la clé affectée est maintenue dans la table de blocage pendant la durée configurée. Cela empêche un attaquant de générer une courte rafale puis de revenir immédiatement après avoir ralenti. Le `blockDuration` est défini par politique. Ce modèle offre un contrôle plus fort contre les vagues intenses de bots et les sources d'abus répétées.
Le CAPTCHA auto-hébergé oriente le trafic suspect vers une vérification plutôt qu'un blocage dur
L'action `captcha` peut rediriger le trafic ayant dépassé le seuil ou signalé comme risqué vers un flux de vérification plutôt que de le couper entièrement. Le fournisseur par défaut est `tr7Standard`. Après vérification réussie, la requête de l'utilisateur se poursuit. Cette approche offre une alternative plus équilibrée au blocage dans les scénarios où séparer les vrais utilisateurs de l'automatisation est la priorité.
Le Bandwidth Limit Rule permet une mise en forme conditionnelle du trafic
TR7 peut suivre les taux de bande passante entrants et sortants en plus des comptages de requêtes. Avec l'action `bwLimit`, le trafic correspondant à une condition spécifique peut être placé sous son propre plafond de bande passante. C'est utile pour les endpoints de téléchargement de fichiers, les endpoints produisant de grandes réponses, ou la consommation de données à volume élevé depuis une seule source — maintenant le backend disponible sans le couper entièrement.
Les variables de session AAM permettent une limitation de débit par utilisateur
Des informations telles que le nom d'utilisateur d'une session AAM peuvent être utilisées comme clé de limitation de débit. Cela permet d'assigner une limite d'utilisation équitable distincte à chaque utilisateur après connexion. Les plans gratuits et payants, les groupes d'utilisateurs internes et externes, ou différents niveaux de rôle peuvent chacun être gouvernés par des limites différentes. Cela fournit un contrôle plus précis dans les scénarios d'API et de portail où les limites basées sur l'IP sont insuffisantes.
Profondeur opérationnelle
Pour que les politiques de limitation de débit soient efficaces, la durée de vie des compteurs, la taille des tables, la synchronisation en cluster, l'observabilité et le comportement de rollback doivent tous être gérés avec clarté opérationnelle.
Dimensionnement adaptatif de la table de compteurs
Différents périmètres fonctionnent avec des tailles de table différentes. Le périmètre global utilise une seule clé tandis que les périmètres IP et composite peuvent contenir un nombre beaucoup plus grand d'entrées. Les clés longues telles que IP combinée avec le user agent peuvent consommer plus de mémoire, la sélection du périmètre doit donc être effectuée en fonction du profil de trafic attendu.
Synchronisation multi-instances
La synchronisation des compteurs entre instances est prise en charge dans les déploiements en cluster. Les instances partageant la même clé de politique peuvent se découvrir mutuellement et échanger l'état des compteurs. Cela rend plus difficile pour un attaquant de contourner une limite en changeant d'instance dans un environnement à charge distribuée.
Continuité des compteurs après rechargement
Un nommage stable des tables lié à l'identité de la politique aide à préserver l'état des compteurs entre les cycles de rechargement. Lorsque la même politique continue sous le même nom, les compteurs ne sont pas réinitialisés inutilement. Cela réduit le risque d'ouverture d'une faille de sécurité lors des maintenances ou des mises à jour de configuration.
Couche de validation des politiques
Les politiques de limitation de débit passent par une validation de schéma avant d'être déployées. Les définitions invalides de périmètre, de type de déclencheur ou d'action ne peuvent pas entrer dans la configuration de production. Cette vérification réduit le risque qu'une règle de sécurité mal configurée perturbe le trafic en production.
Compatibilité de la chaîne d'actions
La politique de bot, les règles de verrouillage de compte et les décisions WAAP peuvent toutes s'exécuter simultanément sur la même requête. L'ordre de priorité et le comportement de correspondance sont gouvernés par la configuration. La limitation de débit fonctionne donc non pas isolément mais comme partie du pipeline de décision WAAP plus large.
Audit et observabilité
À chaque déclenchement, l'identifiant de règle, l'action, la clé et les informations de taux peuvent être journalisés. Ces enregistrements peuvent être transmis à un SIEM pour l'analyse d'incidents et le reporting. Les équipes opérationnelles peuvent surveiller les clés les plus fréquemment déclenchées, les endpoints les plus sollicités et les tendances de blocage au fil du temps.
Quand l'utiliser
Limites par utilisateur et par IP en couches sur une passerelle API
Les organisations qui proposent des API B2B peuvent appliquer simultanément une limite de plan par utilisateur et un plafond d'abus par IP. TR7 exécute en parallèle une politique d'utilisation équitable à périmètre utilisateur et un plafond dur à périmètre IP.
Contrôle des tentatives échouées sur un endpoint de connexion
Un grand nombre de saisies d'identifiants échouées sur un écran d'authentification peut être un indicateur de brute-force. TR7 peut suivre les échecs en utilisant une clé combinée nom d'utilisateur et IP et appliquer des actions escaladées — CAPTCHA d'abord, puis verrouillage temporaire.
Protection par endpoint dans un flux e-commerce
Une courte rafale de requêtes sur des pages produits peut être normale, mais le même pattern sur un endpoint de paiement est un risque. TR7 peut utiliser des conditions d'endpoint et différentes fenêtres temporelles pour limiter l'abus lors du checkout sans dégrader l'expérience de chargement des pages.
Contrôle de bande passante sur le trafic de téléchargement de fichiers
Une seule source peut consommer la capacité I/O d'un backend via des téléchargements à volume élevé. TR7 utilise le Bandwidth Limit Rule pour limiter conditionnellement ce trafic, maintenant le service disponible pour les autres utilisateurs.
Questions fréquentes
Une limite de débit par IP affecte-t-elle les vrais utilisateurs derrière NAT ou une sortie partagée ?
Quelle est la différence entre l'action de blocage et l'action de refus ?
Comment fonctionne l'intégration CAPTCHA auto-hébergé ?
Plusieurs politiques de débit peuvent-elles s'appliquer au même endpoint ?
Le Bandwidth Limit Rule fonctionne-t-il différemment du comptage de requêtes ?
Différentes instances dans un cluster peuvent-elles partager le même compteur ?
Adaptez la limitation de débit au contexte de votre application
Politique de débit multi-couche selon les dimensions IP, utilisateur, clé API et bande passante. Laissez-nous vous guider dans une configuration en direct sur vos propres services.