WAF + Rate Limiting + Bot Management : le tiercé gagnant de la protection des périphéries

L'hypothèse la plus courante des équipes qui viennent d'activer Cloudflare WAF est que l'application est désormais protégée. Cette conclusion est techniquement incorrecte, non pas parce que WAF ne fonctionne pas, mais parce que les attaques qu'il bloque ne constituent qu'un sous-ensemble de celles que vous recevrez. Les deux autres sous-ensembles ont des produits différents, avec des logiques de détection complètement différentes, et les trois sont rarement configurés ensemble dès le départ.

Ce que chaque couche voit réellement

La façon la plus claire de comprendre la division est de réfléchir à trois dimensions de la demande : ce qu’elle contient, combien de personnes arrivent et qui les envoie.

WAF fonctionne sur le contenu : inspecte la charge utile de la requête et vérifie si elle correspond aux modèles d'attaque connus. Un ' OR 1=1 -- dans un paramètre de requête, une balise de script dans un champ de formulaire, une séquence ../../../etc/passwd dans un chemin : ce sont des signatures que le moteur reconnaît et bloque. Le WAF est chirurgical dans la première dimension et aveugle dans les deux autres.

La limitation de débit fonctionne sur la vitesse. Peu importe le contenu de la requête : si une adresse IP envoie 50 tentatives de connexion en dix secondes, quelque chose ne va pas. WAF ne peut pas le détecter car chaque requête individuelle est formellement valide : la requête SQL est correcte, il n'y a pas de charge utile malveillante, la requête HTTP serait acceptée par n'importe quel serveur sans objection. Le problème n'est pas le format, c'est la fréquence.

Le Bot Management opère sur l’identité comportementale. Un robot sophistiqué qui randomise les intervalles entre les requêtes, utilise un pool IP rotatif et maintient les tarifs dans les limites configurées dans Rate Limiting passera par les deux premières couches sans friction. Ce qui génère ce type de trafic, c'est l'empreinte comportementale : modèles de navigation qui n'existent pas dans les sessions humaines, absence d'événements de souris avant la soumission, séquences de requêtes sans les ressources auxiliaires qu'un vrai navigateur chargerait, utilisation d'empreintes digitales TLS associées aux piles d'automatisation. Bot Management note chaque session dans cette dimension comportementale et agit sur le score, quelles que soient la charge utile et la vitesse.

Comment le credential stuffing passe par le WAF et pourquoi la limitation du taux s'impose

L’attaque qui illustre le mieux la nécessité des trois couches est le credential stuffing avec une cadence contrôlée. L'attaquant dispose d'une liste d'informations d'identification divulguées par d'autres services et teste chaque paire par rapport au point de terminaison de connexion de votre application, non pas par rafales, mais méthodiquement, à raison de 3 à 5 tentatives par minute et par IP. Il utilise des proxys résidentiels pour répartir les tentatives et garantit qu'aucune adresse IP individuelle ne dépasse les limites évidentes.

Du point de vue du WAF, cette attaque est invisible. La demande de connexion est un POST avec des champs d'e-mail et de mot de passe, structurellement identique à ce que n'importe quel utilisateur légitime enverrait. Le mot de passe incorrect n'est pas une charge utile malveillante : il s'agit simplement d'un texte qui échouera l'authentification. Il n’y a aucune signature que WAF puisse reconnaître.

Avec Rate Limiting, vous configurez une règle sur le point de terminaison /login avec une fenêtre horaire et une limite de tentatives par IP. Cinq requêtes en dix secondes déclenchent le blocage. Trois requêtes en quinze minutes sur le point final de récupération de mot de passe, idem. L'attaquant qui a calibré votre bot pour qu'il soit en dessous de ce seuil réussira quand même, mais vous avez éliminé la couche de credential stuffing la moins chère : les scripts qui se déclenchent simplement sans contrôle de cadence.

Ce que la limitation de débit ne résout pas, c'est que l'attaquant le distribue sur suffisamment d'adresses IP pour rester en dessous de la limite sur chacune d'entre elles. C'est là qu'intervient Bot Management : même si chaque IP individuelle ne fait que deux tentatives, le score comportemental de la session indiquera une automatisation.

L'architecture du produit et ce que chaque plan débloque

Rate Limiting est un produit distinct de WAF : ce ne sont pas des règles au sein du même système, ce sont des systèmes avec une logique et des configurations indépendantes. Cette distinction est importante lors de la configuration, car les équipes habituées à travailler uniquement avec des règles WAF recherchent souvent le Rate Limiting au mauvais endroit dans l'interface.

Les dimensions de contrôle disponibles dans Rate Limiting incluent l'IP, la combinaison de l'IP et du chemin, le cookie spécifique et l'agent utilisateur. Les actions sont Bloquer, Défier et Journaliser, Log étant l'équivalent du mode surveillance de WAF, utile pour calibrer les seuils avant d'activer le blocage en production.

Le forfait gratuit de Cloudflare autorise une seule règle de limitation de débit. Pro (20 $/mois) va jusqu'à cinq règles. Les affaires s'arrêtent cent. Enterprise supprime la limite des règles et déverrouille la gestion complète des robots, y compris l'accès à cf.bot_management.score en tant que variable dans les expressions de règles – un nombre compris entre 0 et 99 où des valeurs plus faibles indiquent un trafic plus automatisé.

Sur Pro, l'équivalent de Bot Management est le Super Bot Fight Mode : un paramètre simplifié qui bloque les robots définitivement automatisés, défie ceux probablement automatisés et laisse passer le trafic vérifié. Vous n'accédez pas au score numérique et n'écrivez pas de règles basées sur celui-ci, mais la couverture contre les catégories de robots les plus courantes est active.

Ce que couvre la combinaison du plan Pro en pratique

Pour 20 $ par mois, une application Web avec une attention minimale à la configuration peut couvrir la majeure partie de la surface d'attaque automatisée. WAF avec les ensembles de règles gérés par Cloudflare en mode Bloc pour OWASP niveau 1 intercepte SQLi, XSS, la traversée de chemin et l'exploitation des CVE connus. Les cinq règles de limitation de débit couvrent les points de terminaison critiques : connexion avec une limite de cinq requêtes en dix secondes par IP, récupération de mot de passe avec trois requêtes en quinze minutes, enregistrement de compte avec dix requêtes en une heure, point de terminaison de paiement avec dix requêtes en une heure et racine d'API avec cent requêtes par minute. Le mode de combat actif Super Bot bloque le nombre de robots qui n'ont pas suffisamment de sophistication pour dissimuler leur comportement.

Ce que cette combinaison ne couvre pas, ce sont les robots au comportement véritablement humain – des sessions qui naviguent à une vitesse plausible, avec des modèles de souris et de clavier synthétiques mais convaincants, en utilisant des adresses IP domestiques avec des historiques clairs. Ce niveau de sophistication est coûteux pour l'attaquant et rare dans les attaques ciblant des applications qui ne sont pas des cibles de grande valeur. Pour la plupart des applications Web, l'écart laissé dans Pro est acceptable.

Où est-il judicieux d'évoluer vers Business ou Enterprise ?

La décision de procéder à une mise à niveau est une équation de risque et de coût, et non d’ambition technologique. Les entreprises justifient ce saut, surtout si vous avez besoin de plus de cinq règles de limitation de débit : une application avec des dizaines de points de terminaison sensibles épuisera rapidement la limite Pro. Une centaine de règles en entreprise résolvent ce problème sans atteindre l'investissement de l'entreprise.

L’entreprise prend tout son sens lorsque le profil de menace inclut des adversaires capables de contourner la détection simplifiée : fraude financière sophistiquée, concurrents vendant systématiquement des prix avec des robots qui imitent le comportement humain, ou bourrage d’informations d’identification hautement distribué contre un service à forte valeur ajoutée. L'accès au score numérique de Bot Management vous permet de créer des règles avec une granularité que le mode Super Bot Fight n'offre pas : bloquer au-dessus de 30, défier entre 30 et 60, autoriser au-dessus de 60, avec une logique supplémentaire via un chemin ou une méthode HTTP. Cette expressivité a un coût, et ce coût n’est justifié que lorsque le risque atténué est proportionné.