Guide de configuration du rate limiting Cloudflare : bloquer les attaques CC en 5 minutes, même en version gratuite

3 heures du matin. L’alerte monitoring réveille : CPU à 100 %, site inaccessible. Les logs montrent des dizaines d’IP qui martèlent les API — attaque CC.

Bloquer les IP une par une, de nouvelles arrivent aussitôt. Deux heures perdues avant de penser à Cloudflare. Rate Limiting : la version gratuite suffit ! Une règle — 20 requêtes par minute par IP, blocage 10 minutes — configurée en 5 minutes. L’attaque reste dehors.

Défendre contre le CC n’est pas si compliqué : configurez le rate limiting à l’avance. Ce guide couvre la version gratuite, les seuils, les scénarios et les pièges.

Qu’est-ce qu’une attaque CC ? Pourquoi le rate limiting la bloque-t-il

CC signifie Challenge Collapsar : simuler de nombreux utilisateurs normaux pour épuiser les ressources du serveur.

Ce n’est pas exactement un DDoS classique. Le DDoS envoie des paquets massifs, facilement repérables ; la protection DDoS Cloudflare les intercepte. Le CC envoie des requêtes HTTP normales, comme un vrai visiteur ; la protection DDoS peut passer à côté.

Un utilisateur normal : quelques pages par minute, 5 à 10 requêtes. En CC : plus de 1 000 requêtes en 30 secondes depuis une IP — anormal. Souvent des machines ou des IP proxy en masse, trafic dispersé, difficile à filtrer.

Le rate limiting cible précisément ce comportement : surveiller la fréquence par IP (session, clé API, etc.) ; au-delà du seuil, CAPTCHA ou blocage temporaire.

Lors de mon attaque, l’IP envoyait 200 à 300 req/s ; mon seuil : 20/min. Déclenchement en 1 à 2 secondes ; le reste bloqué. Les utilisateurs normaux ne touchaient pas la limite.

Donnée utile : la doc WAF d’Alibaba Cloud indique qu’une machine zombie peut dépasser 1 000 requêtes en 30 secondes ; un utilisateur normal reste sous 10/min.

L’écart est flagrant.

Vous vous demandez peut-être : et si un utilisateur légitime va vite, par exemple en rafraîchissant une API ? C’est pour cela que le seuil compte — voir les recommandations par scénario plus bas.

Version gratuite : panorama du rate limiting Cloudflare

Beaucoup pensent encore que c’est payant. Depuis octobre 2022, Cloudflare l’a ouvert à tous, Free, Pro et Business.

Avant 2022 : facturation au trafic, 5 $ par million de requêtes — j’avais évité de l’activer pour cette raison.

Aujourd’hui : annonce officielle, règles incluses sans surcoût. Free : 1 règle ; Pro et Business : plus.

Une seule règle suffit-elle ? Pour les PME, souvent oui. Placez-la sur la cible la plus exposée : login, inscription ou API critique.

Mes petits projets : 1 règle sur le login, près d’un an sans souci ; scans occasionnels bloqués.

Plusieurs interfaces sensibles ? Pro (20 $/mois, 10 règles) ou Business (200 $/mois, 15 règles). Pour un site perso ou une PME, 1 règle Free couvre l’essentiel.

Rappel : la protection DDoS de base Cloudflare est incluse sans limite de trafic. Le rate limiting cible surtout le CC discret et l’abus d’API.

Free vs payant :

• Nombre de règles : Free 1, Pro 10, Business 15
• Fonctions avancées : Bot Score, JA3, etc.
• Temps de réponse : plans payants plus réactifs sous charge

Débutants : testez en Free sur votre interface la plus critique ; upgradez si besoin.

Seuils : recommandations par scénario

Ma première config : fixer « Requests per period » — 10 ou 100 ? Trop bas, faux positifs ; trop haut, protection faible.

Après doc Cloudflare, bonnes pratiques et tests, voici des repères. À adapter à votre trafic réel.

KiloClaw - OpenClaw managé pour l’entreprise : orchestration d’agents IA et routage intelligent

Commencer →Pub

Login / inscription (cible privilégiée)

Zone de brute force et credential stuffing : trafic utilisateur faible, pic d’attaque élevé.

Recommandation (trois niveaux) :

Cloudflare recommande trois règles :

• Niveau 1 : 4 req/min → JavaScript Challenge
• Niveau 2 : 10 req/10 min → CAPTCHA
• Niveau 3 : 20 req/heure → blocage 1 jour

En Free, simplifiez :

• Une règle : 20 req/60 s → blocage 10 min

D’après mes logs : même avec mots de passe erronés, moins de 5 tentatives/min ; les scripts en envoient des centaines. 20/min équilibre protection et UX.

Sécurité stricte :

• Mode strict : 10 req/60 s → blocage 1 heure

API (selon le métier)

API de requête simple :

• Recommandé : 30 req/10 s → JavaScript Challenge

~3 req/s — suffisant pour la plupart des frontends ; rafraîchissement rapide sans blocage immédiat.

API intensive (images, analytics) :

• Recommandé : 10 req/60 s → limitation

Consommation serveur élevée ; 10/min suffit à l’usage normal et limite l’abus.

API publique :

• Recommandé : selon facturation et capacité

Gratuit : ex. 100 req/heure ; payant : paliers par offre.

Google Cloud Armor suggère parfois 2 000 req/20 min puis limitation à 20 % — approche progressive intéressante.

Pages web (anti-scraping)

Recommandé :

• Pages courantes : 100 req/30 s → JavaScript Challenge
• Pages spéciales (recherche, téléchargement) : 50 req/60 s → CAPTCHA

Seuil élevé car navigation + assets (CSS, JS, images) = plusieurs requêtes par page. 100/30 s ne gêne pas un visiteur ; un crawler à cette cadence est bloqué.

Attention : pas de limite stricte sur la home ! J’avais serré la page d’accueil ; Google et Bing bloqués, SEO en chute. Règle supprimée, récupération.

Cas de référence

Alibaba Cloud WAF — config préventive PME :

• Plus de 1 000 requêtes en 30 s depuis une IP → blocage 10 heures

Filet de sécurité souple ; point de départ si vous hésitez.

Astuce : commencez par Managed Challenge, pas Block ; les humains passent le défi si le seuil est un peu bas. Passez à Block après validation.

Tutoriel en 5 minutes (pas à pas)

Étape 1 : page Rate Limiting

Connexion Cloudflare, choisir le domaine :

Security → WAF → Rate limiting rules

Bouton Create rule ; en Free : 0/1 rules.

Étape 2 : informations de base

Rule name : ex. Login-Rate-Limit ou API-Protection.

Étape 3 : conditions (Expression)

Protéger le login :

Field: URI Path
Operator: equals
Value: /api/login

Surveille uniquement /api/login.

Protéger toute l’API :

Field: URI Path
Operator: contains
Value: /api/

Tous les chemins /api/....

Exclure un User-Agent (ex. script de monitoring) : And

Field: User Agent
Operator: does not equal
Value: MyMonitorBot

Étape 4 : paramètres de rate limiting

Characteristics :

• IP Address : comptage par IP (recommandé contre le CC)
• Session : cookie de session (utilisateurs connectés)
• Headers : ex. clé API

Pour le login : IP Address.

Period : 10 s, 30 s, 60 s… J’utilise 60 s — 10 s risque les faux positifs ; 10 min affaiblit la protection.

Requests per period : login 20, API 30.

Duration : 1 min à 24 h. J’utilise 10 min.

🔥 Ne perdez plus des mois sur des produits sans demande ! Validez vos promesses SaaS avec Adsterra à petit budget →

Tester l'MVP →Pub

Exemple login :

• Characteristics: IP Address
• Period: 60 seconds
• Requests: 20
• Duration: 10 minutes

Plus de 20 accès login/min depuis la même IP → blocage 10 min.

Étape 5 : action (Action)

Managed Challenge — recommandé :

Cloudflare distingue humain et bot ; page de vérification ou passage direct ; impact minimal si erreur.

Block :

403 ; efficace mais gênant si faux positif ; après validation.

Legacy CAPTCHA :

Code à saisir ; UX moyenne, efficace contre les bots.

JS Challenge :

JavaScript côté client ; efficace contre les crawlers, transparent pour les navigateurs.

Commencez par Managed Challenge, puis Block si besoin.

Étape 6 : Deploy

Bouton Deploy en bas — effet immédiat.

Étape 7 : vérification

for i in {1..30}; do curl https://yourdomain.com/api/login; done

20 premières OK ; à partir de la 21e : 429 ou défi.

Consultez Security → Events pour les logs d’interception.

Exemple complet

Interface /api/auth/login :

Informations :

• Rule name: Login-Rate-Limit

Conditions :

• URI Path equals /api/auth/login

Paramètres :

• Characteristics: IP Address
• Period: 60 seconds
• Requests: 20
• Duration: 10 minutes

Action :

• Managed Challenge

Deploy — 5 minutes.

Astuces avancées et pièges courants

Piège 1 : crawlers SEO

Ne serrez pas la home ni tout le site !

Règle globale 50 req/30 s : erreurs Google Search Console en hausse ; crawlers + assets = déclenchement fréquent.

Limitez login et API ; pages de contenu souples ou sans limite.

Recommandations :

• Login, inscription, API : strict
• Contenu : souple ou sans limite
• Home : éviter les limites strictes

Anti-scraping avancé : Bot Management (payant) pour crawlers légitimes vs malveillants.

Piège 2 : contournement Cloudflare

Un ami avait configuré le rate limiting ; l’attaque passait quand même — accès direct à l’IP d’origine.

Pourquoi ?

Cloudflare est un reverse proxy. IP d’origine connue = bypass.

Solutions :

1. Pare-feu : IP Cloudflare uniquement

Listes officielles IPv4/IPv6 ; ports 80 et 443.

Vultr - Serveur cloud NVMe haute performance, 32 emplacements mondiaux, déploiement Docker en un clic

Voir les tarifs →Pub

Linux :

# N'autoriser que les IP Cloudflare
for i in `curl https://www.cloudflare.com/ips-v4`; do
  ufw allow from $i to any port 443 proto tcp
  ufw allow from $i to any port 80 proto tcp
done

2. Renouveler l’IP d’origine si exposée ; ne pas la publier en DNS.

3. Authenticated Origin Pulls — certificat Cloudflare requis côté origine.

Piège 3 : oublier le suivi

Règles figées :

• Seuil trop bas → plaintes utilisateurs
• Trafic en hausse → seuil obsolète
• Nouvelle tactique d’attaque → protection affaiblie

Recommandation :

Mensuellement, Security Analytics :

• Volume bloqué
• Faux positifs
• Taux 429 anormal

Ajustements :

• Peu de 429 → seuil plus bas possible
• Beaucoup de 429 → relever le seuil ou affiner la règle

Astuce 1 : attaques distribuées

Nombreuses IP proxy, chacune sous le seuil — le plafond par IP seul ne suffit pas.

Méthodes :

1. Session/Cookie (pas IP)

Session ID stable ; Characteristics Cookie + nom du cookie.

2. Filtre User-Agent

Scripts avec Python, curl, etc. — condition User-Agent.

3. Bot Management (payant)

Score 1-100 ; règle sur Bot Score < 30. Business ou Enterprise.

Astuce 2 : réponse progressive (payant)

Trois niveaux (payant) :

Niveau 1 (souple) :

• Seuil : ex. 30/min
• Action : JS Challenge

Niveau 2 (moyen) :

• Seuil : ex. 50/10 min
• Action : Managed Challenge

Niveau 3 (strict) :

• Seuil : ex. 100/heure
• Action : Block 24 h

Plus de marge pour les humains ; sanctions croissantes pour les attaquants.

Astuce 3 : protection géographique

Trafic surtout en Chine — limite stricte à l’étranger :

(ip.geoip.country ne "CN") and (http.request.uri.path eq "/api/login")

Attention aux VPN. Préférez Challenge à Block.

En conclusion

L’essentiel : le rate limiting n’est pas compliqué — configurez-le avant l’attaque, pas après l’alerte à 3 h du matin.

Trop de sites réagissent seulement quand l’alarme sonne. Cinq minutes de config valent des nuits tranquilles.

Actions :

1. Configurez une règle maintenant, même sans attaque passée.
2. Commencez par le login — avec 1 règle Free, c’est la priorité.
3. Testez — curl ou rafraîchissements ; vérifiez Security Events.
4. Revoyez chaque mois — Security Analytics, ajustez les seuils.

Dernier rappel : pare-feu origine = IP Cloudflare uniquement ; sinon bypass et règles inutiles.

Questions : documentation Cloudflare ou forums communautaires — la plupart des cas sont déjà documentés.

Que ce guide vous aide à configurer le rate limiting et à tenir le CC à distance.