CF GarageLa spécificité PrestaShop : un cookie de session dès la première visite
Dès l'arrivée d'un visiteur, PrestaShop pose un cookie de session (cookie de panier, identifiant de session). Le cache Cloudflare ne sert pas par défaut les réponses aux requêtes porteuses de cookies, donc sans configuration dédiée, le hit ratio reste au plancher et le proxy n'apporte presque rien. À l'inverse, un « Cache Everything » global casserait les paniers en servant des pages d'autres visiteurs. La bonne configuration est entre les deux.
Le déroulé de configuration recommandé
- Mode SSL/TLS Full (strict). Un certificat valide sur l'origine, jamais Flexible : c'est le réglage qui évite la boucle de redirection HTTPS et garantit que les données de commande circulent chiffrées de bout en bout.
- Cache Rules ciblées sur le catalogue. Mettre en cache les chemins de contenu statique du thème et du catalogue (
/themes/,/js/,/css/,/img/,/c/pour les images catégories) avec un Edge TTL long, et les pages produits/catégories sans état de session. Ne jamais inclure/panier,/commande,/mon-compte,/authentificationni les URLs de module. - Exempter les callbacks de paiement des challenges. Les modules de paiement (Stripe, PayPal, systempay, Mollie...) appellent des URLs
/module/<module>/validationou équivalentes. Ces requêtes automatiques doivent être exemptées de Bot Fight Mode et des règles WAF qui posent challenge, sinon les paiements confirmés côté PSP ne sont jamais validés côté boutique. Utiliser un nom d'exception WAF ciblé sur ces chemins, et vérifier dans Security > Events après chaque incident de paiement. - Protéger le back-office. Le chemin
/adminXXX(renommer le chemin par défaut est la première règle d'hygiène PrestaShop) doit recevoir un traitement renforcé : restriction par pays ou par liste d'IP, challenge sur chaque requête, et exclusion du cache. La quasi-totalité des compromissions PrestaShop commence par du brute force sur le BO. - Restaurer les IP réelles. Derrière le proxy, PrestaShop voit les IP de Cloudflare. La géolocalisation par pays, les restrictions de pays de vente et les journaux de sécurité doivent lire l'en-tête
CF-Connecting-IP, sinon la géolocalisation envoie les visiteurs en Amérique du Nord. Cloudflare fournit l'en-tête nativement : c'est une configuration applicative ou un réglage de module. - Turnstile sur les formulaires sensibles. Le widget Turnstile de Cloudflare remplace les captchas classiques sur l'inscription client, le formulaire de contact et la création de compte. Pour PrestaShop, il s'intègre via module dédié ou sur mesure sur les templates concernés, et l'attention va à l'exemption des callbacks de paiement citée plus haut.
- Valider chaque étape sur un environnement de test. Toute règle de cache ou de sécurité se teste d'abord sur un environnement de staging ou une URL dédiée, avec un parcours d'achat complet : ajout au panier, connexion, paiement test, réception de l'email de confirmation.
Les erreurs qui coûtent des commandes
- Cache-everything global : la page panier d'un client affiche le panier d'un autre, ou une page produit serve une version périmée. Sur un e-commerce, la règle est : mettre en cache par chemin explicite, jamais « tout ».
- WAF qui bloque les callbacks de paiement : les paiements passent chez le PSP mais la boutique reste « en attente » : les requêtes de validation automatique ont été filtrées comme des bots. Le réflexe de dépannage est de vérifier Security > Events à l'heure exacte d'un paiement en échec.
- Géolocalisation faussée non détectée : si la boutique restreint la vente à certains pays et lit l'IP brute, elle peut bloquer des clients légitimes ou en autoriser à tort. À tester systématiquement après activation du proxy.
- Back-office accessible depuis partout : un BO PrestaShop exposé au monde entier derrière un proxy qui n'applique aucune règle spécifique concentre tout le brute force. Un simple challenge sur
/adminXXXélimine l'essentiel du bruit. - Purger sans cibler : lors des mises à jour de catalogue, purger tout le cache à chaque changement de stock fait chuter le hit ratio. Cache Rules par chemin + purge ciblée par URL gardent la boutique rapide pendant les mises à jour.
Questions fréquentes
Peut-on mettre en cache les pages produits PrestaShop chez Cloudflare ?
Oui pour le catalogue, à condition d'exclure les pages à état de session : panier, commande, compte, connexion. PrestaShop pose un cookie dès la première visite, donc la configuration fiable cible explicitement les chemins de catalogue via des Cache Rules et exclut les chemins transactionnels, plutôt qu'un cache-everything global qui mélangerait les sessions.
Pourquoi les paiements ou les webhooks échouent-ils derrière Cloudflare ?
Les URLs de callback des modules de paiement et les endpoints de webhooks reçoivent des requêtes automatiques que le WAF et Bot Fight Mode peuvent traiter comme suspectes. Il faut exempter ces chemins des challenges dans les règles de sécurité, tout en gardant la protection sur le reste de la boutique, et vérifier Security > Events en cas de paiement bloqué.
Comment protéger le back-office PrestaShop avec Cloudflare ?
Utiliser le chemin d'administration personnalisé comme critère de règle : restriction par pays ou liste d'IP, challenge sur chaque requête de ce chemin, exclusion du cache. Combiné au renommage du chemin d'admin, cela élimine l'essentiel des attaques par force brute qui ciblent PrestaShop.
La géolocalisation PrestaShop devient-elle fausse derrière Cloudflare ?
Oui, si l'application lit l'IP de la connexion : elle voit des IP de centres de données Cloudflare. PrestaShop doit lire l'en-tête CF-Connecting-IP pour la géolocalisation et les restrictions par pays, sinon les règles géographiques s'appliquent aux proxys plutôt qu'aux clients réels.