curl -I https://boutique.example/panier/ renvoyant un en-tête cf-cache-status: HIT sur une page panier est le signal qui doit immédiatement alerter : cela signifie que Cloudflare sert une version mise en cache d’une page censée être strictement personnelle à chaque visiteur.
Le cache de page de Cloudflare, activé par défaut à un niveau raisonnable sur le plan gratuit, ne connaît rien de la structure interne de WooCommerce. Sans configuration spécifique, il peut mettre en cache des pages qui contiennent des données de session — panier, compte client, tunnel de commande — exactement comme s’il s’agissait d’une page de blog statique.
Comprendre pourquoi le cache HTTP standard ne suffit pas
Un cache de type Cloudflare fonctionne par défaut sur la base de l’URL, sans tenir compte des cookies de session PHP qui distinguent un visiteur d’un autre. Une page /panier/ mise en cache pour un premier visiteur devient alors la réponse servie à tous les visiteurs suivants qui accèdent à la même URL, tant que le cache reste valide — ce qui peut afficher le contenu du panier, voire des informations de compte, à la mauvaise personne.
Créer des règles de contournement sur les pages sensibles
La correction passe par des Page Rules (ou des règles de cache dans l’interface plus récente de Cloudflare) qui excluent explicitement les URL WooCommerce sensibles du cache :
URL : boutique.example/panier/*
Réglage : Cache Level = Bypass
URL : boutique.example/mon-compte/*
Réglage : Cache Level = Bypass
URL : boutique.example/commande/*
Réglage : Cache Level = BypassCes trois règles couvrent la majorité des cas, mais il faut vérifier les URL exactes selon la configuration des permaliens du site : une boutique avec des permaliens personnalisés ou une boutique multilingue peut avoir des chemins différents à exclure pour chaque langue.
Exclure les cookies de session de la clé de cache
Sur les pages qui doivent rester en cache malgré tout (page d’accueil, fiches produit), il reste utile de vérifier que la présence du cookie woocommerce_items_in_cart ou wp_woocommerce_session_ ne provoque pas de variation de contenu cachée à tort en cache statique. Cloudflare Workers ou une règle de cache par en-tête permet, sur les plans payants, de traiter différemment une requête porteuse de ce cookie — en la faisant systématiquement transiter en direct vers l’origine plutôt qu’en cache.
Vérifier le comportement avec deux sessions distinctes
- Ouvrir une navigation privée, ajouter un produit A au panier
- Ouvrir une seconde navigation privée dans un navigateur différent, ajouter un produit B
- Vérifier dans les deux fenêtres que
/panier/affiche bien le contenu propre à chaque session - Contrôler l’en-tête
cf-cache-statusvia les outils de développement du navigateur : il doit indiquerBYPASSouDYNAMICsur ces pages, jamaisHIT
Le cas particulier du CDN d’images
La mise en cache des images du catalogue (via Cloudflare ou un CDN dédié) ne pose pas ce type de risque : les images ne contiennent aucune donnée de session et peuvent rester en cache longtemps sans conséquence sur la confidentialité. Ce point relève d’une configuration distincte, à ne pas confondre avec la mise en cache des pages HTML dynamiques abordée ici.
Documenter l’incident si le problème a déjà eu lieu
Si l’exposition a déjà eu lieu avant la correction — un client ayant potentiellement vu le panier d’un autre visiteur — la question se pose de savoir si cela constitue une violation de données au sens du RGPD, obligeant à une notification à la CNIL sous 72 heures dans les cas les plus sérieux. Cette qualification dépend du volume de visiteurs concernés, de la nature exacte des données exposées (un simple contenu de panier reste moins sensible qu’une adresse de facturation complète) et de la durée pendant laquelle la faille est restée active. Ce travail de qualification revient au responsable de traitement, généralement accompagné d’un conseil juridique, mais le développeur doit être en mesure de fournir des éléments factuels précis : depuis quand la règle de cache fautive était active, et une estimation du nombre de requêtes concernées à partir des journaux d’accès Cloudflare.
Un tableau de bord Cloudflare Analytics, consultable a posteriori, permet généralement de retrouver le nombre de requêtes ayant reçu un statut HIT sur les URL concernées durant la période à risque, ce qui donne un ordre de grandeur exploitable pour cette qualification, même si tous les visiteurs concernés n’ont pas nécessairement remarqué l’anomalie.
En résumé
Un cache Cloudflare mal configuré sur une boutique WooCommerce ne provoque pas une simple lenteur, mais un risque réel de confidentialité entre visiteurs. Trois règles d’exclusion sur les pages panier, compte et commande, vérifiées avec deux sessions de navigation distinctes, suffisent à couvrir l’essentiel du risque sans renoncer aux bénéfices du cache sur le reste du site.
