Pourquoi les protections applicatives classiques échouent

Les attaques contemporaines n'utilisent plus une seule adresse IP fixe. Les réseaux de bots automatisés exploitent des proxies résidentiels rotatifs et imitent les empreintes de navigateurs légitimes pour contourner les contrôles simples :

  • Inefficacité du blocage par adresse IP simple : Les attaquants répartissent leurs requêtes sur des milliers d'adresses IP distinctes, rendant tout bannissement d'IP unique obsolète en quelques secondes.
  • Friction néfaste des CAPTCHAs visuels traditionnels : Forcer les utilisateurs à identifier des images dégrade drastiquement le taux de conversion tout en étant résolu par des fermes de décodage automatisées ou des modèles IA.
  • Surcharge du serveur d'origine : Vérifier les mots de passe hachés (bcrypt, argon2) ou envoyer un email de confirmation pour chaque tentative sature le processeur et la file d'attente d'envoi.
  • Risque d'attaque par carding (test de cartes bancaires) : Les cybercriminels utilisent les points d'entrée de paiement pour valider des numéros de carte volés par rafales, risquant de déclencher des pénalités Stripe ou bancaires.

Le coût dépasse largement la simple pollution de la base de données. Chaque faux compte déclenche un email de bienvenue vers un fournisseur de messagerie, et ces rebonds répétés apprennent aux filtres antispam à se méfier de votre domaine d'envoi. Une fois que le credential stuffing réussit sur des mots de passe réutilisés, suivent les plaintes de piratage de compte, les tickets de support et les remboursements. La seule défense qui passe à l'échelle s'applique au niveau du bord, avant qu'une seule requête de bot ne consomme des ressources applicatives.

La stratégie de défense multicouche au niveau Edge

Pour intercepter les bots avant même qu'ils ne touchent votre infrastructure backend :

  • Rate Limiting ciblé sur méthodes POST et endpoints sensibles : Définir des quotas stricts basés sur l'IP, le session token ou les en-têtes de requête sur /api/login, /signup et /checkout.
  • Intégration transparente de Cloudflare Turnstile : Remplacer les CAPTCHAs intrusifs par la vérification invisible Cloudflare Turnstile validée côté serveur avant tout traitement applicatif.
  • Filtrage des ASN de centres de données (Datacenter ASN) : Bloquer ou soumettre à un Managed Challenge renforcé les requêtes d'authentification provenant d'hébergeurs de serveurs dédiés (AWS, DigitalOcean, Hetzner, OVH) qui ne correspondent jamais à de vrais internautes.
  • Analyse des en-têtes HTTP de navigation : Vérifier la cohérence des en-têtes modernes (Sec-Fetch-Site, Sec-Fetch-Mode, Referer) pour refouler les scripts cURL et scripts headless primitifs.

La superposition de couches est essentielle car aucune règle isolée n'intercepte tous les botnets. Les proxies résidentiels contournent le filtrage ASN, la répartition temporelle déjoue le rate limiting naïf et les en-têtes falsifiés trompent la correspondance de signatures. Chaque couche élimine une classe d'attaquant, et ce qui subsiste devient assez réduit pour être traité par un CAPTCHA. Si les règles déjà déployées attrapent aussi des clients légitimes, travaillez d'abord avec notre guide sur les faux positifs de sécurité sur les inscriptions et le paiement avant d'ajouter d'autres couches.

Corriger les créations abusives sur Cloudflare, étape par étape

Avant toute modification, quantifiez. Puis déployez l'application des règles progressivement, en vérifiant à chaque étape que les inscriptions légitimes continuent d'aboutir sans friction. Voici la séquence qui fonctionne sur une zone standard :

  1. Mesurer l'attaque. Dans le tableau de bord Cloudflare, ouvrez Security > Events et filtrez sur le chemin du formulaire visé, par exemple http.request.uri.path contains "/signup". Notez le volume de requêtes par heure, les ASN sources principaux, la répartition par pays, et la présence ou non d'en-têtes de navigateur réalistes. C'est votre point de référence ; sans lui, vous ne pourrez pas démontrer l'amélioration ensuite.
  2. Protéger l'endpoint de connexion par une règle de Rate Limiting. Sous Security > WAF > Rate limiting rules, créez une règle qui compte les requêtes correspondantes sur une fenêtre courte. Configuration de départ réaliste contre le credential stuffing : 
Expression :
  (http.request.method == "POST" and http.request.uri.path contains "/login")
Avec la même caractéristique : adresse IP
Comptage : 5 requêtes sur 1 minute
Action : Managed Challenge, timeout de mitigation 10 minutes

Déclinez la même logique pour /signup et, si vous exploitez un e-commerce, pour /checkout afin d'endiguer les rafales de carding. Ajustez le seuil par rapport à votre référence : il doit se situer très en dessous du volume d'attaque observé et confortablement au-dessus du comportement des vrais utilisateurs, y compris les collaborateurs derrière une IP de sortie d'entreprise partagée.

  1. Soumettre à un Managed Challenge les sources suspectes via une règle de sécurité personnalisée. Sous Security > WAF > Custom rules, combinez l'intelligence de menace intégrée de Cloudflare avec la méthode de requête : 
Expression :
  cf.threat_score gt 30 and http.request.method == "POST"
Action : Managed Challenge

Le champ cf.threat_score agrège l'intelligence Cloudflare sur l'IP source : historique de spam, participation à des réseaux de proxies, activité malveillante. Ne bloquez jamais frontalement sur ce score seul ; préférez un CAPTCHA, pour que le rare visiteur légitime derrière une adresse signalée puisse quand même passer.

  1. Exempter les bons bots vérifiés. Si des crawlers de moteurs de recherche ou des outils de supervision POSTent légitimement sur vos endpoints (soumissions de sitemap, vérifications de disponibilité), placez au-dessus des règles de CAPTCHA une règle Skip avec l'expression cf.client.bot. Ce champ managé par Cloudflare ne correspond qu'aux crawlers validés par reverse DNS, jamais aux user agents usurpés.
  2. Ajouter Turnstile au formulaire lui-même. Créez un widget dans la section Turnstile du tableau de bord, intégrez-le dans vos formulaires d'inscription et de connexion, et vérifiez le token côté serveur avant de traiter la soumission. Pour les humains il s'exécute invisiblement ; pour les scripts incapables d'exécuter JavaScript, le formulaire ne valide simplement jamais.
  3. Observer, puis itérer. Retournez dans Security > Events après 24 à 48 heures : la vague de bots doit désormais se heurter à des actions Challenge ou Block, tandis que vos statistiques applicatives confirment que les inscriptions légitimes aboutissent toujours. Ajustez les seuils un cran à la fois, jamais plusieurs, pour que chaque effet reste attribuable.

Les erreurs fréquentes

Voici les erreurs que nous rencontrons le plus souvent en auditant des zones qui restent attaquées alors que Cloudflare est bien devant le site :

  • Filtrer uniquement sur les chaînes de user agent. Une expression comme http.user_agent contains "bot" n'arrête rien de sérieux : la chaîne est trivialement falsifiable par n'importe quel client HTTP, et cette même correspondance large attrape aussi le trafic http.user_agent contains "Googlebot" que vous voulez conserver. Basez vos règles sur des champs que le client ne peut pas falsifier : cf.client.bot, cf.threat_score et les données ASN.
  • Appliquer le Rate Limiting à tous les endpoints d'un coup. Un quota unique et agressif sur tout le domaine punit la navigation normale et étrangle tous ceux qui partagent des IP de sortie : réseaux d'entreprise, universités. Limitez uniquement les méthodes sensibles (POST) et les quelques chemins réellement attaqués.
  • Laisser le mode « I'm Under Attack » activé en permanence. L'interstitiel JavaScript casse tous les clients non navigateurs : applications mobiles, API de serveur à serveur, tâches planifiées et callbacks des prestataires de paiement. C'est un levier d'urgence pour une attaque en cours, pas une configuration de croisière.
  • Bloquer par pays ou ASN sans exceptions. Fermer des régions entières peut stopper la vague en cours, mais coupe aussi de vrais clients et, selon la façon dont la règle est écrite, les robots d'indexation. Si vous devez géo-restreindre, construisez d'abord l'exception des bots vérifiés ; notre guide sur le blocage accidentel de Googlebot et les chutes SEO montre les expressions exactes.
  • Modifier les règles sans point de référence. Si vous ne pouvez pas comparer avant et après, impossible de savoir si l'attaque a cessé ou simplement changé d'endpoint. Capturez les statistiques de Security > Events avant la première modification, et re-mesurez après chacune.

Questions fréquentes

Le rate limiting va-t-il bloquer mes vrais clients ?

Rarement, quand la règle est correctement ciblée. Une limite appliquée aux requêtes POST d'un seul chemin de connexion n'attrape presque jamais un humain, qui tente au pire deux ou trois connexions à la minute. Les problèmes apparaissent quand le même quota couvre tout le domaine ou compte les requêtes GET. Utiliser une action Managed Challenge plutôt qu'un Block sec laisse en outre passer l'humain occasionnel au-delà du seuil.

Quelle différence entre le Bot Fight Mode et les règles de sécurité personnalisées ?

Le Bot Fight Mode est un produit en un clic qui note et soumet à un CAPTCHA les bots suspects, sans aucune configuration possible. Il arrête les attaques simples mais n'est pas réglable, c'est pourquoi il bloque parfois du trafic légitime, comme détaillé dans notre guide sur les faux positifs du Bot Fight Mode. Les règles de sécurité et de Rate Limiting personnalisées sont l'inverse : plus de travail à l'écriture, mais un périmètre calé exactement sur vos endpoints et ajustable dans le temps.

Faut-il bloquer les domaines email jetables au niveau du bord ?

Non. Cloudflare voit la requête HTTP, pas le contenu des champs du formulaire : une règle de sécurité ne peut donc pas tester de manière fiable l'adresse email soumise. Filtrez les domaines jetables dans la logique applicative, et réservez le bord aux défenses volumétriques et d'empreinte : rate limiting, classification ASN et Turnstile.

En combien de temps les nouvelles règles prennent-elles effet ?

Les règles de sécurité et de Rate Limiting se propagent mondialement en quelques secondes après le déploiement, ce qui impose d'autant plus de prudence : une mauvaise expression part dans le monde entier tout aussi vite. Quand le produit le permet, déployez d'abord la nouvelle règle en action Log, vérifiez pendant quelques heures ce qu'elle aurait intercepté, puis passez-la en Managed Challenge ou en blocage avec confiance.

Vos formulaires sont victimes d'assauts de bots ou de spam massif ?

CF Garage déploie des règles de sécurité de sécurité et de Rate Limiting chirurgicales sur votre zone Cloudflare pour stopper le spam sans impacter vos vrais utilisateurs. Tarif fixe, résultat mesuré.

Voir nos offres

Ressources et guides complémentaires