Cloudflare teste son WAF avec des IA : ce que l’automatisation change vraiment en cybersécurité

30 septembre 2026

Cloudflare a décidé de soumettre son propre Web Application Firewall à un test un peu particulier : utiliser des modèles d’IA avancés pour faire varier des attaques en fonction des réponses obtenues.

L’expérience, publiée le 29 septembre 2026, a généré 1 107 tentatives dans un environnement de staging explicitement autorisé. Mais le chiffre est presque secondaire.

Ce qui mérite l’attention des entreprises est la méthode employée.

Contrairement à un scanner qui déroule une batterie de tests prédéfinis, le système pouvait observer le résultat d’une tentative, modifier la manière de présenter le payload et essayer une autre voie.

Autrement dit, l’automatisation ne crée pas soudainement de nouvelles familles de vulnérabilités. Elle permet surtout d’explorer beaucoup plus rapidement les différentes façons d’atteindre celles qui existent déjà. (Cloudflare Blog)

Dans cet article

Cloudflare n’a pas lâché une IA sur Internet
Ce que l’IA change : tester, observer, modifier, recommencer
1 107 tentatives ne signifient pas 1 107 attaques réussies
Pourquoi cette automatisation change quand même la donne
Le WAF reste une protection, pas un correctif
Une défense pragmatique face aux tests automatisés
Que retenir de cet article ?
Sources

Cloudflare n’a pas lâché une IA sur Internet

Premier point important : le test décrit par Cloudflare était encadré et autorisé.

L’entreprise a travaillé sur l’environnement de staging d’un client ayant explicitement autorisé l’opération. Le système était limité au hostname prévu par une allowlist, les redirections étaient désactivées et chaque scénario possédait une limite prédéfinie de tentatives.

Les modèles n’avaient par ailleurs accès ni au code source de l’application, ni aux règles internes du WAF, ni aux identifiants de règles ou aux scores détaillés utilisés par Cloudflare.

Et surtout, les modèles ne contrôlaient pas directement l’exécution.

Cloudflare avait développé en Python un système chargé d’orchestrer les scénarios, d’envoyer les requêtes, d’enregistrer les résultats et de faire respecter les limites. Le modèle proposait une variation ; le programme décidait de ce qui pouvait réellement être envoyé. (Cloudflare Blog)

C’est une distinction importante lorsqu’on parle de sécurité offensive assistée par IA.

Le sujet n’est pas celui d’un agent autonome disposant d’un accès illimité à Internet, mais celui d’un outil de test utilisant un modèle pour décider quelle variation essayer ensuite dans un périmètre contrôlé.

Ce que l’IA change : tester, observer, modifier, recommencer

Un test de sécurité automatisé n’a évidemment rien de nouveau.

Les scanners et outils de Dynamic Application Security Testing savent depuis longtemps envoyer des requêtes malveillantes connues à une application et observer leur résultat.

L’expérience de Cloudflare ajoute cependant une boucle adaptative.

Le système partait d’un exploit connu que le WAF savait bloquer. Le modèle pouvait ensuite proposer une nouvelle façon de le présenter : modifier son encodage, déplacer l’entrée dans une autre partie de la requête ou essayer une autre formulation de la même destination.

La requête était envoyée.

Le résultat était ensuite réinjecté dans une deuxième étape d’analyse afin de déterminer la variation suivante. (Cloudflare Blog)

On passe donc schématiquement de :

payload A → test → résultat

à :

payload A → résultat → mutation B → résultat → mutation C → résultat → autre chemin…

C’est probablement là que se situe le véritable changement.

L’IA apporte trois capacités particulièrement intéressantes à cette automatisation.

Une mutation beaucoup plus rapide des payloads

Un attaquant humain peut évidemment essayer plusieurs encodages et représentations d’une même attaque.

Un modèle peut simplement en produire et en tester davantage, beaucoup plus rapidement, sans avoir à reconstruire manuellement chaque variante.

Une exploitation du retour obtenu

Le test suivant n’est plus totalement indépendant du précédent.

Une réponse qui suggère qu’une variation est passée plus loin qu’une autre peut orienter les essais suivants.

Le système ne se contente donc plus de parcourir une bibliothèque statique : il adapte progressivement son exploration.

Plusieurs chemins peuvent être explorés

Cloudflare a testé différentes catégories d’attaques, différents emplacements dans les requêtes et différentes variantes de payloads.

L’entreprise note d’ailleurs qu’augmenter indéfiniment le nombre d’essais sur un même scénario n’était pas nécessairement efficace : après un certain temps, les modèles avaient tendance à répéter des idées déjà explorées.

Élargir les points de départ, les catégories d’attaques et les emplacements testés s’est révélé plus intéressant que simplement laisser un scénario tourner plus longtemps. (Cloudflare Blog)

L’IA n’apporte donc pas une baguette magique capable de découvrir systématiquement le passage secret.

Elle rend surtout l’exploration plus rapide et plus adaptative.

1 107 tentatives ne signifient pas 1 107 attaques réussies

C’est probablement le chiffre qui risque d’être le plus facilement mal interprété.

Cloudflare a enregistré 1 107 tentatives de mutation, réparties sur 45 scénarios actifs.

Quarante-quatre scénarios couvraient six catégories : XSS, injection SQL, injection de commandes, SSRF, path traversal/LFI et Log4j. Un scénario supplémentaire concernait la log injection et a été traité séparément.

Mais 1 107 ne correspond ni au nombre de vulnérabilités découvertes, ni au nombre de contournements réussis du WAF. (Cloudflare Blog)

Après traitement, Cloudflare a retenu un ensemble de 607 résultats : 558 requêtes avaient été bloquées et 49 observations ont été considérées comme suffisamment pertinentes pour faire l’objet d’une investigation.

Les autres essais pouvaient notamment correspondre à une requête HTTP inutilisable, un échec avant d’atteindre la cible ou encore un payload devenu bénin au fil de ses transformations.

Et même lorsqu’une requête n’était pas bloquée, Cloudflare ne la considérait pas automatiquement comme une faille.

Les équipes devaient notamment vérifier que la requête avait réellement été envoyée, qu’elle n’avait effectivement pas été bloquée, que son contenu restait malveillant, que le comportement relevait bien du périmètre du WAF et que le cas pouvait être reproduit de manière sûre.

Après cette revue humaine, 49 résultats ont été conservés pour investigation, dont 48 concernaient les catégories injection de commandes et SSRF. (Cloudflare Blog)

Cloudflare résume d’ailleurs assez clairement la limite de l’automatisation : le modèle générait les requêtes, mais les humains décidaient lesquelles avaient réellement de l’importance.

Sans cette validation humaine, il n’y avait pas de finding.

C’est un rappel utile à une époque où un rapport généré automatiquement peut facilement produire 300 alertes et donner l’impression d’avoir découvert 300 vulnérabilités.

Pourquoi cette automatisation change quand même la donne

Il serait tout aussi trompeur de conclure que rien ne change.

Ce type d’outil réduit le coût nécessaire pour explorer les variations d’une attaque connue.

Pour une entreprise exploitant un site e-commerce, une API, un extranet ou une application métier exposée sur Internet, la conséquence est assez concrète : une protection qui fonctionne uniquement parce qu’elle reconnaît quelques représentations connues d’un payload devient plus facile à éprouver à grande échelle.

Une règle peut parfaitement bloquer :

attaque → représentation A

et laisser passer :

même attaque → représentation B

La recherche de cette représentation B demandait déjà du temps et de l’expertise. Une boucle automatisée capable de tester, observer et recommencer permet d’en explorer davantage.

C’est notamment ce que montre le travail réalisé par Cloudflare : certains résultats ont conduit à renforcer des règles existantes, d’autres à travailler sur la normalisation des requêtes ou à identifier un contrôle de sécurité différent comme meilleur endroit pour intervenir. (Cloudflare Blog)

L’enjeu pour les entreprises n’est donc pas de savoir si elles vont être attaquées demain par un hypothétique « hacker IA ».

Il est beaucoup plus banal : l’automatisation réduit progressivement l’effort nécessaire pour tester une application de manière répétée et adaptative.

Cela renforce l’intérêt de défenses qui ne dépendent pas d’une seule signature ou d’un seul équipement.

Le WAF reste une protection, pas un correctif

L’expérience contient d’ailleurs un rappel essentiel : contourner le WAF ne suffit pas pour compromettre une application.

Encore faut-il que l’application située derrière soit réellement vulnérable au payload qui lui parvient.

Cloudflare recommande donc explicitement de maintenir les logiciels à jour et rappelle qu’un WAF constitue une couche de protection supplémentaire, pas un remplacement du patching. (Cloudflare Blog)

C’est probablement la conséquence opérationnelle la plus importante de toute l’expérience.

Un CMS, un framework, une extension ou une dépendance présentant une vulnérabilité exploitable reste le problème principal.

Le WAF peut intercepter l’exploitation, fournir une protection supplémentaire ou servir de mesure temporaire lorsqu’un correctif ne peut pas être déployé immédiatement. Mais faire reposer durablement la sécurité d’une application vulnérable sur la capacité d’une règle à reconnaître toutes les variations possibles d’une attaque devient encore moins confortable lorsque ces variations peuvent être générées automatiquement.

OWASP fait d’ailleurs la même distinction concernant le virtual patching : une protection intermédiaire peut réduire le risque et le délai d’exposition, mais elle ne constitue pas nécessairement une correction complète de la vulnérabilité. (OWASP Cheat Sheet Series)

Une défense pragmatique face aux tests automatisés

Pas besoin pour autant de reconstruire toute son infrastructure parce que Cloudflare a donné un LLM à son équipe sécurité.

Quelques priorités deviennent simplement encore plus importantes.

1. Corriger les vulnérabilités à la source

CMS, frameworks, bibliothèques, modules, plugins et composants exposés doivent être maintenus.

Le WAF vient compléter cette politique, pas la remplacer.

2. Vérifier que le WAF protège réellement l’application

Installer Cloudflare ou un autre reverse proxy devant un domaine ne suffit pas à considérer le sujet comme réglé.

Les règles managées doivent être activées et leur comportement surveillé. Et lorsqu’on ajuste les protections Cloudflare, il faut aussi vérifier que l’on ne finit pas par ⁠bloquer involontairement des robots légitimes comme Googlebot.

Attention cependant au réflexe consistant à tout passer au niveau de sensibilité maximal : davantage de règles signifie aussi potentiellement davantage de faux positifs.

La protection doit être testée sur le trafic de l’entreprise.

3. Ajouter un modèle positif lorsque c’est possible

Un WAF cherche traditionnellement notamment à reconnaître ce qui ressemble à une attaque.

Un modèle positif prend le problème dans l’autre sens : à quoi une requête légitime est-elle censée ressembler ?

Une API qui attend un entier sur un paramètre donné, une liste précise de méthodes HTTP ou une structure définie peut refuser ce qui sort de ce contrat.

Cette approche réduit le nombre de variantes qu’un système automatisé peut utilement explorer. OWASP recommande également l’allowlisting des entrées lorsque leur structure peut être définie précisément. (OWASP Cheat Sheet Series)

Cloudflare pousse désormais lui-même cette logique avec ses Application Profiles, destinés à apprendre la structure des requêtes attendues et à identifier celles qui s’en écartent. (Cloudflare Blog)

4. Réduire la surface d’attaque

Un endpoint inutilisé n’a généralement aucune bonne raison de rester accessible publiquement.

Même logique pour une ancienne API, une interface d’administration ouverte à Internet, un environnement de développement oublié ou un service qui pourrait être limité à quelques adresses IP.

Moins l’application expose de chemins, moins un système automatisé dispose de terrain à explorer.

Pour certaines zones sensibles, des règles d’allowlist réseau peuvent par exemple limiter l’accès à des IP explicitement autorisées. (Cloudflare Docs)

5. Surveiller ce qui se passe réellement

Les journaux WAF, erreurs applicatives, anomalies HTTP, répétitions inhabituelles de requêtes et variations rapides autour d’un même endpoint deviennent particulièrement intéressants.

Un système adaptatif peut changer son payload à chaque requête tout en conservant le même objectif.

La surveillance doit donc regarder au-delà de la simple répétition d’une signature identique.

6. Tester régulièrement sa propre défense

C’est finalement la partie la plus intéressante de l’expérience Cloudflare.

Les mêmes capacités d’automatisation peuvent être utilisées par les défenseurs.

Une application critique peut être régulièrement testée sur un environnement de staging reproduisant les protections de production. Cloudflare recommande d’ailleurs, lorsqu’une entreprise réalise déjà des tests de sécurité applicative, de les exécuter contre un hostname de staging protégé par les mêmes contrôles que la production. (Cloudflare Blog)

Le principe est simple : mieux vaut découvrir soi-même qu’une variation passe au travers du WAF que laisser quelqu’un d’autre effectuer le test.

L’automatisation augmente la vitesse des essais.

Elle peut aussi augmenter la fréquence des contrôles défensifs.

Et c’est probablement une lecture beaucoup plus utile du test de Cloudflare que l’inévitable « l’IA apprend maintenant à pirater les sites ».

Que retenir de cet article ?

Cloudflare a testé son WAF avec des modèles IA avancés dans un environnement de staging autorisé et strictement encadré.
Le système a enregistré 1 107 tentatives de mutation sur 45 scénarios ; ce chiffre ne correspond pas à 1 107 vulnérabilités ou contournements réussis.
Après traitement, 558 requêtes avaient été bloquées et 49 observations ont été retenues pour investigation après revue humaine.
Une requête non bloquée n’était jamais automatiquement considérée comme une vulnérabilité : la validation humaine faisait partie intégrante du processus.
L’apport principal de l’IA réside dans sa capacité à modifier rapidement les payloads, apprendre des réponses précédentes et explorer plusieurs chemins.
Pour les entreprises, cela renforce surtout des principes déjà connus : patcher les applications, configurer correctement le WAF, réduire la surface exposée et surveiller le trafic.
Un modèle positif, définissant ce qu’une requête légitime est censée contenir, peut compléter efficacement la recherche de signatures malveillantes.
Les entreprises peuvent également retourner cette automatisation à leur avantage en testant régulièrement leurs propres applications et protections.