Cloudflare utilise des agents d'IA pour tester la robustesse de son propre pare-feu d'applications web

Les ingénieurs de Cloudflare ont récemment soumis leur propre Web Application Firewall (WAF) à un test de résistance rigoureux utilisant des grands modèles de langage (LLM) de pointe. Publiée le 29 septembre 2026, l'étude détaille comment un système automatisé a agi en tant que hacker adversaire, itérant à travers des milliers de variations de charge utile pour trouver des angles morts dans les défenses en temps réel. L'expérience a révélé des faiblesses spécifiques dans la gestion des tentatives d'obfuscation de falsification de requêtes côté serveur (SSRF) et d'injection de commandes, entraînant des mises à jour immédiates des règles gérées par Cloudflare.

Ce qui s'est passé

L'équipe de sécurité a construit un banc d'essai personnalisé basé sur Python pour évaluer si les modèles d'IA modernes pouvaient contourner les protections du WAF plus efficacement que les outils d'analyse statique ou dynamique traditionnels. Contrairement aux tests d'intrusion standards, ce système utilisait des LLM pour faire muter dynamiquement les vecteurs d'attaque en fonction des réponses HTTP en direct. Le testeur n'avait aucun accès au code source ni aux règles internes du WAF, se reposant uniquement sur les données de réponse sélectionnées pour guider son prochain mouvement. Cette approche boîte noire imitait la manière dont un attaquant externe pourrait sonder une application protégée sans connaissance préalable de son infrastructure.

Le test a été réalisé contre un environnement de préproduction client autorisé, configuré avec les paramètres les plus stricts de Cloudflare, incluant le blocage par score d'attaque WAF à 30 ou moins et le Core Ruleset OWASP au niveau de paranoïa 3. Au cours de l'expérience, le système a exécuté 1 107 tentatives de mutation à travers 45 scénarios couvrant six grandes catégories d'attaque : cross-site scripting, injection SQL, injection de commandes, falsification de requêtes côté serveur (SSRF), traversée de chemin et exploits Log4j. Bien que la majorité des attaques aient été bloquées, le processus a identifié 49 résultats spécifiques nécessitant une revue humaine et une mitigation ultérieure.

La plupart des contournements réussis relevaient de deux catégories : l'injection de commandes et la falsification de requêtes côté serveur. Par exemple, dans un scénario SSRF, le modèle a découvert que représenter une adresse IP de métadonnées cloud avec un point final lui permettait d'échapper à la détection là où les représentations décimales ou octales standard échouaient. Ces résultats n'étaient pas des exploits confirmés mais plutôt des pistes indiquant que la logique de normalisation du WAF pouvait traiter certains cas limites différemment. L'équipe a utilisé ces informations pour affiner ses moteurs de détection, aboutissant à de nouvelles règles pour les hôtes obfusqués et les protocoles restreints.

Comment cela fonctionne

Le système de test opère sur une boucle adaptative pilotée par deux appels distincts de LLM par itération. Le premier appel, la phase de proposition, reçoit le contexte de la requête initiale et un historique des résultats précédents pour suggérer une nouvelle variation. Il peut modifier l'encodage, déplacer la charge utile vers une autre partie de la requête HTTP ou altérer le format de destination. Le second appel, la phase de revue, analyse le statut de la réponse, les en-têtes et le corps pour déterminer si la tentative a réussi ou a été bloquée. Cette boucle de rétroaction permet au modèle d'apprendre quelles mutations sont efficaces sans jamais voir les expressions de règles WAF sous-jacentes ou les scores d'attaque.

De manière cruciale, le code maintient un contrôle strict sur l'environnement d'exécution. Le LLM n'envoie pas directement les requêtes ; il génère plutôt des suggestions que le banc d'essai Python valide et exécute. Avant chaque requête, le système vérifie le nom d'hôte cible par rapport à une liste blanche, désactive les redirections et impose une limite stricte sur les tentatives. Après chaque réponse, le système enregistre des preuves structurées, traitant tout texte renvoyé comme une entrée non fiable. Cette conception garantit que le processus de test reste sûr et reproductible, empêchant l'IA de causer des dommages involontaires ou de divulguer des données sensibles lors de l'évaluation.

Détails clés

• Le test a généré 1 107 tentatives de mutation, dont 558 ont été explicitement bloquées par le WAF avant d'atteindre l'application.
• La triage humain a réduit la sortie brute à 49 résultats valides, dont 48 étaient liés à l'injection de commandes ou au SSRF.
• La configuration du WAF incluait le blocage par score d'attaque WAF à 30 ou moins et le Core Ruleset OWASP au niveau de paranoïa 3.
• De nouvelles détections pour les hôtes obfusqués SSRF et les protocoles restreints ont été ajoutées au Managed Ruleset après le test.
• Le système utilisait deux appels LLM séparés par itération : un pour proposer des mutations et un pour examiner les réponses.
• Les requêtes ayant contourné le WAF ont été traitées comme des pistes pour investigation, et non comme des exploits confirmés, nécessitant une validation supplémentaire.

Pourquoi c'est important

Pour les ingénieurs logiciels et les responsables de la sécurité, cette étude met en lumière les limites des défenses statiques basées sur des règles face à des adversaires adaptatifs. Les tests d'intrusion traditionnels suivent souvent des scripts prédéfinis, manquant des techniques d'encodage novatrices ou des failles logiques qu'une IA peut découvrir par itération. En démontrant que les LLM peuvent trouver des failles même dans des WAF hautement configurés, Cloudflare souligne la nécessité de tests de sécurité continus et automatisés qui évoluent parallèlement aux paysages de menaces. Cela suggère que compter uniquement sur la détection basée sur les signatures est insuffisant lorsque les attaquants peuvent utiliser l'IA pour générer des variations infinies d'exploits connus.

Les résultats renforcent également l'importance de la défense en profondeur. Même lorsqu'un WAF ne parvient pas à bloquer une requête mutée spécifique, l'application elle-même doit rester sécurisée. Dans l'exemple SSRF, le contournement n'a pas entraîné d'exfiltration de données car la couche applicative disposait probablement de ses propres protections ou la requête était malformée d'une manière qui empêchait l'exploitation réelle. Cela rappelle aux développeurs que la correction des logiciels et la mise à jour des dépendances sont des compléments critiques aux contrôles de sécurité réseau. Un WAF est un bouclier, pas un remède, et son efficacité dépend de la résilience de toute la pile technologique.

Ce que vous pouvez faire

• Activez tous les jeux de règles gérés disponibles et définissez les seuils de score d'attaque WAF aux niveaux recommandés pour votre profil de risque.
• Exécutez les tests de sécurité d'application existants contre des environnements de préproduction protégés par les mêmes configurations WAF que la production.
• Implémentez des contrôles de sécurité positifs qui définissent les formes de requêtes attendues, réduisant la surface d'attaque pour les variantes inconnues.
• Passez en revue les événements de sécurité en mode journal uniquement avant d'appliquer de nouvelles règles afin d'identifier les faux positifs et les motifs de trafic légitime.
• Maintenez les dépendances et frameworks de l'application à jour pour atténuer les vulnérabilités qui pourraient être exposées si les couches WAF échouent.
• Envisagez d'utiliser des outils de test pilotés par l'IA pour compléter les tests d'intrusion manuels, en mettant l'accent sur la mutation adaptative des charges utiles.