Illustration conceptuelle du trajet de la requête et de la réponse décrit dans l’article : une requête, un panneau de sécurité, l’origine, une étape d’inspection et deux issues possibles, transmise ou bloquée. Il ne s’agit pas de l’architecture réelle de Cloudflare.
Cloudflare a introduit des fonctions de pare-feu applicatif web qui examinent les requêtes HTTP en même temps que les réponses de l’origine. L’approche aide à distinguer les requêtes suspectes des indices montrant qu’une exploitation a pu réussir, tout en permettant de bloquer certaines réponses avant qu’elles n’atteignent le demandeur.
Un pare-feu applicatif web peut repérer une tentative d’accès à un fichier sensible avant que la requête n’atteigne une application. Mais lorsque cette requête est autorisée à passer, une autre question devient importante : comment l’application a-t-elle répondu ?
L’annonce de Cloudflare illustre le problème avec un point de terminaison hypothétique de téléchargement de fichiers qui reçoit cette requête :
GET /download?file=../../config/database.ini
La séquence de traversée de répertoires (path traversal) suggère une tentative de sortir du répertoire de téléchargement autorisé. Un pare-feu applicatif web (WAF) fondé sur les requêtes pourrait repérer ce motif et le bloquer avant que l’origine ne le traite.
Si la requête atteint l’application, en revanche, son contenu seul ne permet pas d’établir le résultat. Le serveur pourrait rejeter le chemin, renvoyer une erreur ou exposer un fichier de configuration.
Le 21 octobre 2026, Cloudflare a introduit la détection sur la transaction complète (full-transaction detection), qui étend son WAF à l’évaluation des requêtes HTTP entrantes conjointement avec les réponses correspondantes de l’origine.
L’entreprise a aussi introduit des règles de réponse (response rules) qui peuvent empêcher certaines réponses de l’origine d’atteindre le demandeur.
Sur le principe, le changement technique est simple : les défenseurs disposent d’une occasion supplémentaire d’évaluer un échange HTTP après que l’application a traité la requête, au lieu de s’en remettre entièrement aux indicateurs visibles avant.
Suivre la requête à travers le WAF de Cloudflare
Un WAF en phase de requête intervient avant que l’application d’origine ne traite une requête entrante.
Cloudflare peut examiner des propriétés comme le chemin de l’URL, les paramètres de requête, les en-têtes et les autres données de requête disponibles. Selon les règles configurées, il peut autoriser la requête, la bloquer ou appliquer une autre action prise en charge.
Dans l’exemple du téléchargement de fichiers, un blocage précoce empêcherait l’origine de traiter la tentative de traversée.
Mais les applications n’interprètent pas toutes les entrées suspectes de la même façon. Une charge utile donnée peut être inoffensive dans un environnement et exploitable dans un autre, en raison de différences de routage, de validation des entrées, de permissions du système de fichiers ou de comportement de l’application.
La détection sur la transaction complète introduit un second point d’observation.
Lorsqu’une requête parvient jusqu’à l’origine, Cloudflare peut corréler la requête initiale avec la réponse HTTP produite par l’application. Des signatures de détection gérées peuvent prendre en compte des signaux de la réponse en plus de l’entrée suspecte, afin de repérer des indices compatibles avec une exploitation.
Supposons que le point de terminaison de téléchargement renvoie un HTTP 200 et un contenu reconnaissable comme un fichier de configuration protégé. Cette combinaison peut étayer une conclusion plus solide sur une exposition d’informations que la seule chaîne de traversée.
Le code d’état à lui seul ne prouverait pas l’exposition. L’indice pertinent serait la relation entre l’opération demandée et ce que la réponse contenait réellement.
Si une règle de blocage en phase de réponse correspond, Cloudflare peut remplacer la réponse de l’origine par une page de blocage du WAF (servie avec un HTTP 403 dans l’exemple de Cloudflare) ou par une alternative configurée, au lieu de transmettre la réponse d’origine.
Le modèle de traitement qui en résulte comporte deux points d’application : l’un avant que l’origine n’exécute la requête, l’autre après la réponse de l’origine mais avant que cette réponse ne soit transmise.
Schéma conceptuel TechiesJournal du modèle de traitement décrit dans l’article, et non schéma officiel de Cloudflare.
Version texte de la figure 1
- Un client envoie une requête HTTP.
- Avant l’origine : le WAF en phase de requête est le point d’application 1. S’il bloque, la requête est rejetée avant l’origine.
- S’il laisse continuer, l’origine traite la requête et produit une réponse HTTP.
- Après la réponse de l’origine et avant la transmission : les signaux de la requête et de la réponse sont corrélés.
- La règle de réponse est le point d’application 2. Si elle autorise ou journalise, la réponse de l’origine est transmise. Si elle bloque, la réponse est remplacée par un blocage du WAF.
Ce que change l’examen de la réponse
Une requête suspecte peut révéler une tentative d’attaque sans prouver que l’application était vulnérable.
Les informations de la réponse peuvent aider à établir si l’application s’est comportée d’une manière compatible avec une exploitation réussie.
Une charge utile de traversée de répertoires suivie d’une réponse « accès refusé » ne signifie pas la même chose qu’une charge suivie de données de configuration privées reconnaissables. De même, une entrée suspecte qui ne produit qu’une erreur générique n’apporte pas les mêmes indices qu’une réponse contenant des informations normalement inaccessibles au demandeur.
Les premières détections sur la transaction complète de Cloudflare portent sur une sélection de vulnérabilités très médiatisées. L’entreprise dit avoir l’intention d’étendre la couverture à d’autres formes d’exposition et d’exfiltration de données.
Ce contexte supplémentaire peut améliorer l’analyse du trafic suspect, en particulier lorsque de grands volumes de sondes rendent difficile la priorisation des alertes fondées uniquement sur les requêtes.
Ce n’est pas une méthode universelle pour déterminer si une attaque a réussi. Certaines attaques réussies ne produisent aucune réponse HTTP caractéristique, tandis que des réponses légitimes de l’application peuvent parfois ressembler à une sortie suspecte.
Sa valeur dépend des signatures de détection, du comportement propre à l’application et de la relation entre les indicateurs côté requête et côté réponse.
Métadonnées de détection et règles de réponse
Cloudflare sépare la détection de la mise en application.
Une détection repère un motif correspondant et met le résultat à disposition sous forme de métadonnées de la transaction. Une règle détermine si ce résultat doit être journalisé ou servir à bloquer la réponse.
Pour les signatures sur la transaction complète, Cloudflare a introduit trois champs de métadonnées côté réponse :
| Champ | Signification |
|---|---|
cf.waf.signature.response.confidence | Valeurs de confiance des signatures correspondantes |
cf.waf.signature.response.categories | Catégories associées aux signatures correspondantes |
cf.waf.signature.response.ref | Identifiants de référence des signatures correspondantes, jusqu’à 10 |
Ces champs permettent aux équipes de sécurité de combiner les résultats de détection côté réponse avec le contexte de la requête pour créer des politiques sur mesure.
Par exemple, une équipe pourrait appliquer une restriction supplémentaire à un chemin d’administration sensible, sans toucher aux autres routes de l’application.
Une règle de réponse peut aussi fonctionner sans ces champs de signature, en évaluant directement les propriétés de la requête et de la réponse.
L’exemple publié par Cloudflare combine un préfixe d’URL /admin, un en-tête de requête représentant une authentification interne, une réponse HTTP 200 et un type de contenu HTML.
La règle vise à bloquer une réponse réussie d’une page d’administration lorsque le marqueur d’authentification attendu est absent, sans traiter chaque visite de /admin comme une exposition.
Cette distinction est utile, car les règles de réponse peuvent tenir compte du comportement HTTP réel de l’origine, et pas seulement de l’URL de la requête.
Lorsqu’une règle de réponse configurée bloque une transaction, la réponse de l’origine est remplacée avant d’être transmise au demandeur.
Cependant, bloquer une réponse n’annule pas les actions déjà effectuées par l’application, comme le souligne l’annonce de Cloudflare.
Si la requête a provoqué une modification de la base de données, exécuté une commande ou déclenché une autre opération côté serveur, la règle de réponse ne peut pas inverser cet effet de bord.
Le blocage en phase de réponse est donc un mécanisme de confinement pour certaines divulgations dans les réponses, et non un substitut à la protection en phase de requête, à l’autorisation au niveau de l’application ou à la correction des vulnérabilités.
Qu’est-ce qui est disponible pour les clients de Cloudflare ?
Selon l’annonce de Cloudflare du 21 octobre, la détection sur la transaction complète est en disponibilité générale pour les zones dont le trafic passe par le proxy de Cloudflare.
Les protections de réponse gérées et les règles de réponse personnalisées ont été publiées pour toutes les offres, y compris l’offre Free.
Cloudflare fournit un ensemble de règles de réponse géré, le Cloudflare Managed Response Firewall Default, qui, selon Cloudflare, s’exécute par défaut sur chaque requête et qui, d’après son billet sur PHP, a été déployé automatiquement pour les clients de toutes les offres, y compris Free. Les clients sont donc couverts sans avoir à construire de politiques individuelles fondées sur des signatures. Une règle gérée correspondante peut bloquer la réponse et renvoyer une page de blocage standard du WAF. La portée peut être ajustée pour limiter les endroits où ces protections s’appliquent.
Toutes les offres permettent aussi de créer jusqu’à trois règles de réponse personnalisées, avec les actions Log et Block. Ces règles peuvent combiner les propriétés de requête et de réponse disponibles dans l’offre du client.
Il existe deux restrictions importantes.
Premièrement, les règles de réponse personnalisées ne peuvent pas encore porter sur le corps de la réponse. Les signatures gérées de détection sur la transaction complète de Cloudflare peuvent examiner des signaux de la réponse, mais les clients ne peuvent pas encore écrire leurs propres conditions sur le corps de la réponse.
Deuxièmement, les nouveaux champs cf.waf.signature.response.*, qui servent à bâtir des politiques sur mesure à partir des détections gérées, sont destinés aux clients payants. Cloudflare a indiqué que ces champs étaient encore en cours de déploiement sur les comptes clients au moment de l’annonce de la fonction.
Il ne faut donc pas confondre la disponibilité du moteur de règles de réponse avec l’accès à tous les champs de détection.
Les administrateurs trouvent les contrôles en phase de réponse sous Security → Security Rules dans le tableau de bord Cloudflare. Cloudflare expose aussi les informations de détection pertinentes dans Security Analytics et enregistre les actions des règles correspondantes dans Security Events.
Pour une application en production, la première tâche consiste à examiner quelles signatures correspondent, à repérer les routes concernées et à décider si l’action de réponse configurée est appropriée. Une politique de blocage large peut être inutile lorsque l’exposition en cause se limite à un point de terminaison particulier.
Pourquoi la réponse à PHP2Shell a compté
Cloudflare a introduit cette nouvelle fonction en développant des protections contre les vulnérabilités PHP d’octobre 2026, couramment appelées PHP2Shell.
L’entreprise a décrit des attaquants qui modifiaient les charges utiles de leurs requêtes pour tenter de contourner les protections antérieures fondées sur les requêtes. L’examen des réponses de l’origine a apporté des indices supplémentaires sur les tentatives qui avaient pu réussir.
Cette expérience a contribué aux premières signatures sur la transaction complète.
TechiesJournal a déjà traité les vulnérabilités et les correctifs nécessaires dans son rapport de sécurité sur PHP2Shell (en anglais). Ce qui compte ici, c’est le modèle de traitement du WAF issu de ces efforts défensifs.
Au lieu de s’appuyer exclusivement sur des motifs de requête suspects, le système peut désormais utiliser certains signaux de la réponse de l’application pour appuyer la détection et la mise en application.
C’est particulièrement pertinent pour les divulgations potentielles d’informations, où la réponse elle-même peut contenir des indices de ce qui est sorti de l’application.
Cela ne dispense pas de corriger le logiciel vulnérable. Une règle de réponse peut parfois empêcher la transmission d’informations, mais elle ne peut ni garantir que chaque exploit produira une réponse détectable, ni arrêter des dommages déjà accomplis sur l’origine.
Ce que cela change pour les opérations de sécurité
Pour les équipes de sécurité applicative, la distinction pratique se fait entre empêcher l’exécution, contenir une réponse et analyser le résultat.
Les contrôles en phase de requête peuvent arrêter une opération suspecte avant que l’application ne la traite.
Les contrôles en phase de réponse peuvent empêcher une réponse correspondante de l’origine d’atteindre le client une fois le traitement effectué.
La corrélation requête-réponse peut fournir des indices supplémentaires pour l’investigation des incidents, en aidant les intervenants à distinguer les tentatives d’attaque de l’activité associée à un impact observable.
Ces capacités se complètent, mais elles n’assurent pas la même fonction de sécurité.
La détection sur la transaction complète de Cloudflare apporte de la visibilité sur une partie de l’échange HTTP que l’inspection des seules requêtes ne peut pas expliquer. Ses règles de réponse créent un point d’application correspondant avant que certains contenus de l’origine ne quittent la périphérie du réseau (edge).
Le changement important, c’est qu’un WAF peut désormais s’appuyer sur des indices de la façon dont une application a répondu, et pas seulement sur ce que le demandeur a tenté, pour prendre certaines décisions de détection et de confinement. La limite qui subsiste est tout aussi importante : une fois que l’origine a effectué une action, bloquer sa réponse ne peut pas annuler cette action.
Pour aller plus loin
- Cloudflare: Introducing full transaction detection for Cloudflare WAF, Daniele Molteni, Elie Roudninski et Nick Downie, 21 octobre 2026. Présentation technique et produit de première main sur la détection sur la transaction complète, les règles de réponse, les métadonnées de signature, la disponibilité et les limites de la mise en application.
- Cloudflare: Cloudflare deploys protections against php2shell vulnerability, Daniele Molteni, Dan Jones et Kuber Nandwani, 21 octobre 2026, mis à jour le 23 octobre 2026. Contexte opérationnel de la réponse aux vulnérabilités PHP, qui a contribué aux travaux de Cloudflare sur la détection à partir de la requête et de la réponse.
- Cloudflare Developer Documentation: Attack Signature Detection. Documentation de référence sur la séparation, chez Cloudflare, entre la détection des attaques et leur atténuation. Les nouveaux champs de métadonnées propres aux réponses sont décrits dans l’annonce du 21 octobre.
- À lire aussi sur ce site : Vulnérabilités critiques de PHP : qui est concerné, ce qui pourrait arriver et comment corriger en toute sécurité (en anglais), sur les vulnérabilités et les correctifs nécessaires, à distinguer de l’architecture du WAF examinée ici.
Révision des sources : 26 octobre 2026. Le comportement du produit, la disponibilité selon les offres et les informations de déploiement proviennent de la communication officielle de Cloudflare. Cet article ne revendique aucune validation indépendante de l’efficacité du système de détection.