Problèmes de cookies PrestaShop : erreurs de session, RGPD et performances

Comment PrestaShop utilise les cookies

Chaque boutique PrestaShop dépend des cookies pour fonctionner. Ils maintiennent les sessions clients, mémorisent le contenu du panier, stockent les préférences de langue et de devise, suivent l'état de connexion et permettent au back-office d'authentifier les administrateurs. Sans cookies, une boutique PrestaShop ne peut pas maintenir l'état entre les chargements de pages, ce qui signifie pas de panier, pas de connexion client et pas d'accès administrateur.

PrestaShop utilise deux cookies principaux. Le cookie du front-office, généralement nommé d'après votre boutique (comme PrestaShop-abc123), gère tout ce dont le côté client a besoin. Le cookie du back-office, avec un modèle de nommage similaire mais une portée différente, gère l'authentification des administrateurs. Les deux cookies stockent des données sérialisées directement dans la valeur du cookie, ce qui est une décision de conception ayant des implications significatives pour les performances, la sécurité et la conformité RGPD.

Structure et contenu du cookie PrestaShop

Contrairement à de nombreuses applications web qui ne stockent qu'un identifiant de session dans le cookie et conservent toutes les données de session sur le serveur, PrestaShop stocke des données substantielles directement dans le cookie lui-même. Le cookie du front-office contient des champs incluant l'identifiant client, le nom et l'email du client, si le client est connecté, l'identifiant du panier, la langue sélectionnée, la devise sélectionnée, la dernière catégorie visitée, le dernier produit visité, l'étape du processus de commande et diverses autres informations d'état.

Ces données sont sérialisées en utilisant la classe cookie propre à PrestaShop (Cookie.php dans le répertoire classes). La valeur du cookie est chiffrée à l'aide d'une clé dérivée de votre constante _COOKIE_KEY_ dans config/settings.inc.php (PrestaShop 1.6/1.7) ou app/config/parameters.php (PrestaShop 8.x). Ce chiffrement empêche la falsification et protège les données sensibles comme l'identifiant client et l'email d'être lisibles dans le navigateur.

Pourquoi PrestaShop stocke les données dans le cookie

La raison historique de cette conception est la performance. En stockant les données de session dans le cookie, PrestaShop évite une recherche de session côté serveur à chaque requête. Il n'est pas nécessaire de lire un fichier de session, d'interroger une base de données ou de se connecter à un serveur de sessions. Les données arrivent avec la requête, déjà disponibles.

Cependant, cette approche présente des inconvénients qui deviennent plus pertinents à mesure que les boutiques grandissent. La taille du cookie augmente avec la quantité de données stockées, et chaque requête HTTP (y compris les requêtes pour les images, CSS et fichiers JavaScript) envoie le cookie complet au serveur. Un cookie de 4 Ko envoyé avec 30 requêtes de ressources par page signifie 120 Ko de bande passante de téléchargement inutile par chargement de page. Cette surcharge est mesurable sur les connexions mobiles et à grande échelle.

Taille des cookies et impact sur les performances

Les cookies de navigateur ont une limite de taille pratique d'environ 4 096 octets par cookie. Le cookie du front-office de PrestaShop peut approcher ou dépasser cette limite, surtout lorsque des modules ajoutent leurs propres données au cookie via le hookActionBeforeSubmitAccount ou en modifiant directement l'objet cookie.

Mesurer l'impact de la taille des cookies

Pour voir comment les cookies affectent les performances de votre boutique, ouvrez les outils de développement de votre navigateur et allez à l'onglet Réseau. Regardez les en-têtes de requête pour n'importe quelle requête vers votre domaine. L'en-tête Cookie montre tous les cookies envoyés. Notez sa taille. Regardez maintenant les en-têtes de requête pour une ressource statique (une image ou un fichier CSS) sur le même domaine. Les mêmes cookies sont envoyés avec cette requête aussi, ajoutant une surcharge sans raison.

Réduire la surcharge des cookies pour les ressources statiques

Le moyen le plus efficace d'éliminer la surcharge des cookies pour les fichiers statiques est de les servir depuis un domaine différent (un domaine sans cookies). Dans PrestaShop, vous pouvez configurer des serveurs de médias dans le back-office sous Paramètres avancés > Performances. Lorsque vous configurez un serveur de médias comme static.votredomaine.fr, PrestaShop sert les images, CSS et JavaScript depuis ce domaine. Comme les cookies sont spécifiques au domaine, aucun cookie n'est envoyé avec les requêtes vers le domaine média.

Alternativement, un CDN comme Cloudflare, Fastly ou CloudFront peut servir vos ressources statiques. Les serveurs edge CDN suppriment généralement les cookies des réponses mises en cache, de sorte que même si des cookies sont envoyés dans la requête, la réponse provient du cache sans la surcharge d'un aller-retour vers votre serveur d'origine.

Gonflement des cookies par les modules

Les modules tiers ajoutent parfois des données au cookie PrestaShop sans considérer les implications de taille. Chaque module qui stocke une valeur dans le cookie augmente sa taille et la surcharge sur chaque requête. Si votre cookie est anormalement volumineux, vérifiez quelles données les modules ont ajoutées en examinant le contenu déchiffré du cookie ou en examinant le code du module pour les appels à $this->context->cookie->mymodule_value = ....

Les modules bien conçus utilisent un stockage côté serveur (base de données ou cache) et ne stockent au plus qu'un petit identifiant dans le cookie. Les modules mal conçus déversent des structures de données complètes dans le cookie, gonflant sa taille. Si vous identifiez un module problématique, contactez le développeur ou remplacez le stockage par cookie par un stockage en base de données utilisant un identifiant de session.

Gestion des sessions : fichiers, base de données et Redis

Bien que PrestaShop stocke certaines données directement dans les cookies, PHP maintient également son propre système de sessions. Le back-office de PrestaShop repose plus lourdement sur les sessions PHP que le front-office. Le gestionnaire de sessions détermine où les données de session sont stockées côté serveur.

Sessions basées sur les fichiers (par défaut)

Par défaut, PHP stocke les sessions sous forme de fichiers dans le répertoire session.save_path (typiquement /tmp ou /var/lib/php/sessions). Chaque session crée un fichier. Pour une boutique avec des milliers de sessions actives, cela signifie des milliers de petits fichiers. Les sessions basées sur les fichiers fonctionnent bien pour les petites et moyennes boutiques mais peuvent causer des problèmes à grande échelle.

Les problèmes courants avec les sessions basées sur les fichiers comprennent un ramassage de sessions lent lorsque le répertoire de sessions contient trop de fichiers, le verrouillage de fichiers pouvant causer une sérialisation des requêtes (deux requêtes de la même session ne peuvent pas être traitées simultanément), et les environnements d'hébergement mutualisé où le répertoire de sessions se remplit ou a des permissions restrictives.

Sessions en base de données

PrestaShop prend en charge le stockage des sessions dans la base de données. Cela se configure dans les paramètres PHP ou via le gestionnaire de sessions de PrestaShop. Les sessions en base de données éliminent les problèmes de système de fichiers mais ajoutent une requête de base de données à chaque requête. Pour les boutiques avec une charge de base de données déjà élevée, cela peut aggraver les performances. Cependant, les sessions en base de données ont l'avantage d'être partagées entre plusieurs serveurs web dans une configuration à répartition de charge.

Sessions Redis ou Memcached

Pour les boutiques PrestaShop à fort trafic, Redis est le backend de stockage de sessions optimal. Redis stocke les données de session en mémoire, offrant des temps d'accès inférieurs à la milliseconde. Il prend en charge l'expiration automatique (délai d'expiration de session), et les données de session sont partagées entre toutes les instances de serveur web.

Pour configurer PHP afin d'utiliser Redis pour les sessions, définissez session.save_handler = redis et session.save_path = "tcp://127.0.0.1:6379" dans votre php.ini ou configuration du pool PHP-FPM. Si votre instance Redis nécessite une authentification, ajoutez le mot de passe au chemin de sauvegarde : "tcp://127.0.0.1:6379?auth=votremotdepasse".

PrestaShop prend déjà en charge Redis pour le cache d'objets (configuré dans le back-office sous Paramètres avancés > Performances). Utiliser la même instance Redis pour les sessions et le cache d'objets simplifie votre infrastructure tout en offrant d'excellentes performances pour les deux.

Attributs SameSite, Secure et HttpOnly

Les navigateurs modernes appliquent des attributs de sécurité des cookies qui affectent directement le comportement des cookies PrestaShop. Des attributs de cookies mal configurés provoquent des échecs de connexion, des paniers perdus et des erreurs de traitement de paiement.

Attribut SameSite

L'attribut SameSite contrôle si un cookie est envoyé avec les requêtes inter-sites. Il a trois valeurs possibles :

SameSite=Strict signifie que le cookie n'est jamais envoyé avec les requêtes inter-sites. C'est trop restrictif pour PrestaShop car les clients qui cliquent sur un lien vers votre boutique depuis un email ou un post sur les réseaux sociaux n'auraient pas leur cookie de session envoyé, les déconnectant effectivement.

SameSite=Lax est la valeur par défaut dans les navigateurs modernes. Le cookie est envoyé avec les navigations de niveau supérieur (clic sur un lien) mais pas avec les sous-requêtes inter-sites (images, iframes, AJAX). Cela fonctionne bien pour le cookie du front-office de PrestaShop dans la plupart des cas.

SameSite=None signifie que le cookie est toujours envoyé, y compris avec les requêtes inter-sites. Cela doit être associé à l'attribut Secure. C'est nécessaire lorsque votre boutique est intégrée dans un iframe sur un autre site ou lorsque des passerelles de paiement tierces doivent rediriger vers votre boutique avec la session intacte.

Problèmes de passerelle de paiement

De nombreux problèmes de paiement PrestaShop sont causés par des problèmes de cookies SameSite. Le scénario typique est : un client passe à la caisse, est redirigé vers le site de la passerelle de paiement, termine le paiement et est redirigé vers votre boutique. Si le cookie de session a SameSite=Lax, il peut ne pas être envoyé lors de la redirection depuis la passerelle de paiement, selon la façon dont la redirection est implémentée. Si la passerelle utilise une redirection POST (courante avec 3D Secure), la politique Lax bloque le cookie et PrestaShop perd la session. Le client voit un panier vide ou une page d'erreur générique au lieu de la confirmation de commande.

La solution est de définir le cookie PrestaShop sur SameSite=None; Secure. Dans PrestaShop 1.7.7+ et 8.x, cela peut être configuré dans les paramètres de cookies. Pour les versions plus anciennes, vous devrez peut-être modifier la classe Cookie ou ajouter des en-têtes via la configuration de votre serveur web. Testez toujours les flux de paiement après avoir modifié les paramètres SameSite.

Attribut Secure

L'attribut Secure garantit que le cookie n'est envoyé que sur des connexions HTTPS. Si votre boutique fonctionne en HTTPS (ce qui devrait être le cas), cet attribut empêche le cookie d'être transmis sur une connexion non chiffrée, le protégeant de l'interception. PrestaShop définit cet attribut lorsque la boutique détecte une connexion HTTPS.

Un problème courant survient avec les configurations HTTP/HTTPS mixtes. Si votre back-office est en HTTPS mais que certaines pages du front-office sont en HTTP, les cookies marqués comme Secure ne seront pas envoyés sur les pages HTTP, cassant la session. La solution est d'imposer HTTPS partout, ce que vous devriez faire de toute façon pour des raisons de sécurité et de SEO.

Attribut HttpOnly

L'attribut HttpOnly empêche JavaScript d'accéder au cookie via document.cookie. C'est une mesure de sécurité critique contre les attaques de type cross-site scripting (XSS). Si un attaquant injecte du JavaScript malveillant dans votre boutique (via un module vulnérable, par exemple), l'attribut HttpOnly empêche ce code de voler les cookies de session.

PrestaShop définit le flag HttpOnly sur ses cookies par défaut. Ne le désactivez pas sauf si vous avez une raison très spécifique et que vous comprenez les implications de sécurité.

Débogage des problèmes de session et de cookies

Les problèmes de cookies et de sessions se manifestent par des symptômes mystérieux : clients déconnectés aléatoirement, paniers qui se vident tout seuls, sessions admin qui expirent immédiatement, processus de commande qui échouent silencieusement. Un débogage systématique nécessite de vérifier plusieurs couches.

Outils de développement du navigateur

Ouvrez l'onglet Application (Chrome) ou Stockage (Firefox) et naviguez vers Cookies. Trouvez le domaine de votre boutique et examinez tous les cookies. Vérifiez les colonnes Nom, Valeur, Domaine, Chemin, Expiration, Taille, HttpOnly, Secure et SameSite. Recherchez les cookies anormalement volumineux, ceux ayant des paramètres de domaine incorrects (un cookie pour www.exemple.fr ne sera pas envoyé à exemple.fr), ou ceux auxquels manquent des attributs de sécurité.

Vérification des sessions côté serveur

Si les sessions sont stockées dans des fichiers, vérifiez le répertoire de sessions pour la présence et l'âge des fichiers de session. Si un client signale avoir été déconnecté, trouvez son fichier de session (le nom de fichier est l'identifiant de session du cookie PHPSESSID) et vérifiez quand il a été modifié pour la dernière fois. Si le fichier est manquant, la session a été soit nettoyée par le ramassage, soit jamais créée correctement.

Pour les sessions Redis, utilisez redis-cli pour vérifier si la clé de session existe : EXISTS PHPREDIS_SESSION:session_id. Vérifiez le TTL pour voir s'il est sur le point d'expirer : TTL PHPREDIS_SESSION:session_id.

Causes courantes de déconnexions aléatoires

Le _COOKIE_KEY_ a changé. Si cette clé change (lors d'un déploiement mal configuré, d'un écrasement du fichier de paramètres ou d'une mise à jour), tous les cookies existants deviennent illisibles car ils ont été chiffrés avec l'ancienne clé. Chaque client est effectivement déconnecté. La solution est de restaurer la clé originale depuis une sauvegarde.

Le ramassage des sessions est trop agressif. La valeur session.gc_maxlifetime de PHP détermine combien de temps (en secondes) un fichier de session est considéré comme valide. Si cette valeur est trop basse (la valeur par défaut est 1440 secondes, soit 24 minutes), les sessions des clients qui naviguent lentement sont supprimées. Pour une boutique, définissez cette valeur à au moins 3600 (1 heure) ou plus.

Répartiteur de charge sans affinité de session. Si votre boutique fonctionne sur plusieurs serveurs web derrière un répartiteur de charge et que les sessions sont stockées dans des fichiers, chaque serveur a son propre répertoire de sessions. Un client dont les requêtes alternent entre les serveurs perdra sa session à chaque changement. La solution est soit l'affinité de session (sessions persistantes) sur le répartiteur de charge, soit un stockage de session partagé via Redis ou une base de données.

Incompatibilité de domaine de cookie. Si votre boutique est accessible à la fois sur www.exemple.fr et exemple.fr, mais que le domaine du cookie est défini sur www.exemple.fr, les clients qui accèdent au site sans le préfixe www n'auront pas le cookie. Assurez une utilisation cohérente du domaine avec une redirection et vérifiez le domaine du cookie dans les paramètres de PrestaShop.

Conformité cookies et RGPD

Le Règlement Général sur la Protection des Données (RGPD) et la directive ePrivacy exigent un consentement éclairé avant de placer des cookies non essentiels sur le navigateur d'un utilisateur. Les boutiques PrestaShop doivent se conformer à ces réglementations, et le non-respect peut entraîner des amendes significatives.

Cookies essentiels vs non essentiels

Le RGPD distingue les cookies strictement nécessaires au fonctionnement du site web et les cookies servant d'autres objectifs comme l'analyse, le marketing ou la personnalisation. Le cookie de session de PrestaShop est essentiel car la boutique ne peut pas fonctionner sans. Un client ne peut pas ajouter de produits au panier ni effectuer un achat sans cookie de session. Les cookies essentiels ne nécessitent pas de consentement en vertu du RGPD.

Cependant, de nombreux autres cookies couramment trouvés sur les boutiques PrestaShop sont non essentiels et nécessitent un consentement explicite avant d'être placés. Ceux-ci incluent les cookies de suivi Google Analytics (_ga, _gid), les cookies du pixel Facebook, les cookies publicitaires des plateformes de remarketing, les cookies de widgets de chat en direct, les cookies de boutons de partage sur les réseaux sociaux et tous les cookies placés par des modules tiers à des fins de suivi ou de personnalisation.

Implémentation du consentement aux cookies

PrestaShop n'inclut pas de mécanisme de consentement aux cookies intégré répondant aux exigences du RGPD. Vous avez besoin soit d'un module PrestaShop conçu pour le consentement aux cookies, soit d'une intégration avec une plateforme de gestion du consentement (CMP) comme Cookiebot, Osano ou Usercentrics.

Une implémentation correcte du consentement aux cookies doit présenter un choix clair à l'utilisateur avant que tout cookie non essentiel ne soit placé. Elle doit permettre à l'utilisateur d'accepter ou de refuser des catégories individuelles de cookies (analyse, marketing, etc.), et pas seulement offrir un choix tout ou rien. Elle doit mémoriser le choix de l'utilisateur et ne pas redemander jusqu'à l'expiration du consentement. Et elle doit effectivement empêcher les cookies bloqués d'être placés, pas simplement enregistrer la préférence tout en continuant à charger les codes de suivi.

Ce dernier point est critique et souvent mal géré. Une bannière de consentement qui s'affiche mais charge Google Analytics de toute façon, quelle que soit la décision de l'utilisateur, n'offre aucune protection juridique. L'implémentation doit charger conditionnellement les ressources de suivi et de marketing en fonction du consentement de l'utilisateur.

Implémentation technique du consentement

L'approche technique de la gestion des cookies basée sur le consentement consiste à envelopper le code non essentiel dans des vérifications de consentement. Pour le JavaScript en ligne qui place des cookies ou charge des pixels de suivi, l'exécution directe est remplacée par un chargeur conditionné au consentement. Le code de suivi est stocké mais pas exécuté tant que l'utilisateur ne donne pas son consentement.

Pour les modules tiers qui placent des cookies, l'implémentation est plus complexe. Certains modules fournissent des hooks ou des options de configuration pour l'intégration du consentement. D'autres chargent leurs cookies sans condition et doivent être modifiés ou remplacés. Auditez chaque module de votre boutique pour l'utilisation de cookies et déterminez lesquels placent des cookies non essentiels.

Consentement aux cookies et mise en cache

La mise en cache de pages complètes crée un conflit avec le consentement aux cookies. Si une page est mise en cache avec Google Analytics chargé et servie à un utilisateur qui n'a pas donné son consentement, vous violez le RGPD. Il existe deux approches pour gérer cela.

La première approche consiste à mettre en cache la page sans aucune ressource non essentielle et à les injecter dynamiquement via JavaScript après vérification du consentement. Cela fonctionne bien avec le système CCC (Combine, Compress, Cache) de PrestaShop et avec Varnish ou d'autres caches reverse proxy.

La deuxième approche consiste à ne pas mettre en cache les pages pour les utilisateurs qui n'ont pas encore fait de choix de consentement (premiers visiteurs). Cela nuit aux performances pour les nouveaux visiteurs mais assure la conformité. La plupart des plateformes de gestion du consentement utilisent la première approche car elle préserve les avantages de la mise en cache.

Préoccupations de sécurité liées aux cookies

Au-delà des attributs HttpOnly et Secure déjà abordés, il existe des considérations de sécurité supplémentaires pour les cookies PrestaShop.

Vol de cookies et détournement de session

Si un attaquant obtient un cookie de session PrestaShop valide, il peut usurper l'identité du client ou de l'administrateur. La protection principale est HTTPS partout (empêche l'interception), les cookies HttpOnly (empêchent le vol par XSS) et l'attribut Secure (empêche la transmission via HTTP). PrestaShop lie également les sessions aux adresses IP dans certaines configurations, ce qui fournit une couche de protection supplémentaire mais peut causer des problèmes pour les utilisateurs dont l'adresse IP change (utilisateurs mobiles, utilisateurs VPN).

Sécurité de la clé de cookie

Le _COOKIE_KEY_ dans votre configuration PrestaShop est la clé maîtresse pour le chiffrement des cookies. Si cette clé est compromise, un attaquant peut déchiffrer tout cookie PrestaShop et forger des cookies de session valides. Protégez cette clé en restreignant l'accès à vos fichiers de configuration, en ne la committant jamais dans des dépôts publics et en ne la partageant jamais dans des demandes de support.

Prévention de la fixation de cookie

Les attaques par fixation de session impliquent qu'un attaquant définisse un identifiant de session connu dans le navigateur de la victime avant que celle-ci ne se connecte. Lorsque la victime se connecte, l'identifiant de session prédéfini par l'attaquant devient authentifié. PrestaShop atténue ce risque en régénérant l'identifiant de session lors de la connexion. Assurez-vous que la régénération de l'identifiant de session fonctionne correctement et n'a pas été désactivée par un module ou une modification de configuration.

Résolution des problèmes courants de cookies

Boucle de connexion du panneau d'administration

Le symptôme est de saisir des identifiants valides dans le back-office PrestaShop, de voir brièvement le tableau de bord et d'être redirigé vers la page de connexion. C'est presque toujours un problème de cookie. Vérifiez que le domaine du cookie est correct, que le nom du répertoire admin n'a pas changé, que HTTPS est correctement configuré (le contenu mixte peut empêcher l'envoi du cookie Secure), et que le répertoire de stockage des sessions est accessible en écriture par le serveur web.

Panier qui se vide lors de la navigation

Si le panier se vide lorsque le client navigue vers une autre page, le cookie de session n'est pas maintenu. Les causes courantes incluent un paramètre de domaine de cookie manquant ou incorrect, un session.cookie_lifetime mal configuré dans PHP (la valeur 0 signifie que le cookie expire à la fermeture du navigateur, ce qui est correct, mais certaines configurations le définissent à un temps très court), ou un CDN ou une couche de mise en cache qui supprime l'en-tête Set-Cookie des réponses.

Échec du paiement après la commande

Lorsque les clients terminent le paiement mais voient une erreur ou un panier vide au retour vers votre boutique, la politique de cookies SameSite est généralement la cause, comme décrit dans la section sur les passerelles de paiement ci-dessus. Testez le flux complet de commande avec les outils de développement du navigateur ouverts, en surveillant les cookies à chaque étape pour identifier où la session est perdue.

Plusieurs boutiques sur le même domaine

Si vous exécutez plusieurs installations PrestaShop sur le même domaine (par exemple, dans des sous-répertoires), leurs cookies peuvent entrer en conflit. Chaque installation utilise un nom de cookie similaire, et si le chemin du cookie est défini sur /, le cookie d'une boutique écrase celui de l'autre. Définissez des noms de cookies uniques pour chaque installation via le _COOKIE_KEY_ (qui affecte le nom du cookie) ou configurez le chemin du cookie pour correspondre au sous-répertoire de chaque installation.

Optimisation de la configuration des cookies pour les performances

Une configuration de cookies PrestaShop bien optimisée minimise la surcharge tout en maintenant la fonctionnalité. Utilisez un domaine sans cookies ou un CDN pour les ressources statiques afin d'éviter d'envoyer des cookies avec les requêtes d'images, CSS et JavaScript. Gardez la taille des cookies petite en empêchant les modules de stocker des données inutiles. Définissez des délais d'expiration de session appropriés qui équilibrent la sécurité (plus court est plus sûr) avec l'expérience utilisateur (plus long signifie moins de reconnexions). Utilisez Redis pour le stockage des sessions pour combiner un accès rapide avec un état partagé entre les instances de serveur. Activez les attributs Secure et HttpOnly pour protéger l'intégrité des cookies sans affecter les performances. Implémentez un consentement aux cookies approprié pour éviter de charger des cookies de suivi inutiles qui ajoutent de la surcharge et du risque juridique.

Chacune de ces optimisations est petite individuellement, mais ensemble elles créent une amélioration significative tant des performances que de la conformité. La gestion des cookies n'est pas un travail glamour, mais elle sous-tend chaque interaction entre votre boutique et vos clients, ce qui mérite qu'on s'en occupe correctement.