PrestaShop Cookie Problems: Session Issues, GDPR and Performance

How PrestaShop Uses Cookies

Every PrestaShop store relies on cookies to function. They maintain customer sessions, remember cart contents, store language and currency preferences, track logged-in status, and enable the back office to authenticate administrators. Without cookies, a PrestaShop store cannot maintain state between page loads, which means no shopping cart, no customer login, and no admin access.

PrestaShop uses two primary cookies. The front office cookie, typically named after your store (like PrestaShop-abc123), handles everything the customer-facing side needs. The back office cookie, with a similar naming pattern but different scope, handles administrator authentication. Both cookies store serialized data directly in the cookie value, which is a design decision that has significant implications for performance, security, and GDPR compliance.

PrestaShop Cookie Structure and Contents

Unlike many web applications that store only a session ID in the cookie and keep all session data on the server, PrestaShop stores substantial data directly in the cookie itself. The front office cookie contains fields including the customer ID, customer name and email, whether the customer is logged in, the cart ID, the selected language, the selected currency, the last visited category, the last visited product, the checkout step, and various other state information.

This data is serialized using PrestaShop's own cookie class (Cookie.php in the classes directory). The cookie value is encrypted using a key derived from your _COOKIE_KEY_ constant in config/settings.inc.php (PrestaShop 1.6/1.7) or app/config/parameters.php (PrestaShop 8.x). This encryption prevents tampering and protects sensitive data like the customer ID and email from being readable in the browser.

Why PrestaShop Stores Data in the Cookie

The historical reason for this design is performance. By storing session data in the cookie, PrestaShop avoids a server-side session lookup on every request. There is no need to read from a session file, query a database, or connect to a session server. The data arrives with the request, already available.

However, this approach has downsides that become more relevant as stores grow. The cookie size increases with the amount of stored data, and every HTTP request (including requests for images, CSS, and JavaScript files) sends the full cookie to the server. A 4 KB cookie sent with 30 asset requests per page means 120 KB of unnecessary upload bandwidth per page load. This overhead is measurable on mobile connections and at scale.

Cookie Size and Performance Impact

Browser cookies have a practical size limit of around 4,096 bytes per cookie. PrestaShop's front office cookie can approach or exceed this limit, especially when modules add their own data to the cookie through the hookActionBeforeSubmitAccount or by directly modifying the cookie object.

Measuring Cookie Size Impact

To see how cookies affect your store's performance, open your browser's developer tools and go to the Network tab. Look at the request headers for any request to your domain. The Cookie header shows all cookies being sent. Note its size. Now look at the request headers for a static asset (an image or CSS file) on the same domain. The same cookies are sent with that request too, adding overhead for no reason.

Reducing Cookie Overhead for Static Assets

The most effective way to eliminate cookie overhead for static files is to serve them from a different domain (a cookieless domain). In PrestaShop, you can configure media servers in the back office under Advanced Parameters > Performance. When you set a media server like static.yourdomain.com, PrestaShop serves images, CSS, and JavaScript from that domain. Since cookies are domain-specific, no cookies are sent with requests to the media domain.

Alternatively, a CDN like Cloudflare, Fastly, or CloudFront can serve your static assets. CDN edge servers typically strip cookies from cached responses, so even if cookies are sent in the request, the response comes from cache without the overhead of a round trip to your origin server.

Module Cookie Bloat

Third-party modules sometimes add data to the PrestaShop cookie without considering size implications. Each module that stores a value in the cookie increases its size and the overhead on every request. If your cookie is unusually large, check what data modules have added by examining the decrypted cookie contents or by reviewing module code for calls to $this->context->cookie->mymodule_value = ....

Well-designed modules use server-side storage (database or cache) and store at most a small identifier in the cookie. Poorly designed modules dump full data structures into the cookie, inflating its size. If you identify a problematic module, contact the developer or replace the cookie storage with database-backed storage using a session identifier.

Session Handling: Files, Database, and Redis

While PrestaShop stores some data directly in cookies, PHP also maintains its own session system. PrestaShop's back office relies more heavily on PHP sessions than the front office. The session handler determines where session data is stored on the server side.

File-Based Sessions (Default)

By default, PHP stores sessions as files in the session.save_path directory (typically /tmp or /var/lib/php/sessions). Each session creates a file. For a store with thousands of active sessions, this means thousands of small files. File-based sessions work well for small to medium stores but can cause problems at scale.

Common issues with file-based sessions include slow session garbage collection when the session directory contains too many files, file locking that can cause request serialization (two requests from the same session cannot be processed simultaneously), and shared hosting environments where the session directory fills up or has restrictive permissions.

Database Sessions

PrestaShop supports storing sessions in the database. This is configured in PHP settings or through PrestaShop's session handler. Database sessions eliminate the file system issues but add a database query to every request. For stores that already have high database load, this can worsen performance. However, database sessions have the advantage of being shared across multiple web servers in a load-balanced setup.

Redis or Memcached Sessions

For high-traffic PrestaShop stores, Redis is the optimal session storage backend. Redis stores session data in memory, providing sub-millisecond access times. It supports automatic expiration (session timeout), and session data is shared across all web server instances.

To configure PHP to use Redis for sessions, set session.save_handler = redis and session.save_path = "tcp://127.0.0.1:6379" in your php.ini or PHP-FPM pool configuration. If your Redis instance requires authentication, add the password to the save path: "tcp://127.0.0.1:6379?auth=yourpassword".

PrestaShop already supports Redis for object caching (configured in the back office under Advanced Parameters > Performance). Using the same Redis instance for both sessions and object caching simplifies your infrastructure while providing excellent performance for both.

SameSite, Secure, and HttpOnly Attributes

Modern browsers enforce cookie security attributes that directly affect how PrestaShop cookies behave. Misconfigured cookie attributes cause login failures, lost carts, and payment processing errors.

SameSite Attribute

The SameSite attribute controls whether a cookie is sent with cross-site requests. It has three possible values:

SameSite=Strict means the cookie is never sent with cross-site requests. This is too restrictive for PrestaShop because customers clicking a link to your store from an email or social media post would not have their session cookie sent, effectively logging them out.

SameSite=Lax is the default in modern browsers. The cookie is sent with top-level navigations (clicking a link) but not with cross-site subrequests (images, iframes, AJAX). This works well for PrestaShop's front office cookie in most cases.

SameSite=None means the cookie is always sent, including with cross-site requests. This must be paired with the Secure attribute. It is needed when your store is embedded in an iframe on another site or when third-party payment gateways need to redirect back to your store with the session intact.

Payment Gateway Issues

Many PrestaShop payment problems are caused by SameSite cookie issues. The typical scenario is: a customer checks out, is redirected to the payment gateway's site, completes payment, and is redirected back to your store. If the session cookie has SameSite=Lax, it may not be sent on the redirect back from the payment gateway, depending on how the redirect is implemented. If the gateway uses a POST redirect (common with 3D Secure), the Lax policy blocks the cookie, and PrestaShop loses the session. The customer sees an empty cart or a generic error page instead of the order confirmation.

The fix is to set the PrestaShop cookie to SameSite=None; Secure. In PrestaShop 1.7.7+ and 8.x, this can be configured in the cookie settings. For older versions, you may need to modify the Cookie class or add headers through your web server configuration. Always test payment flows after changing SameSite settings.

Secure Attribute

The Secure attribute ensures the cookie is only sent over HTTPS connections. If your store runs on HTTPS (which it should), this attribute prevents the cookie from being transmitted over an unencrypted connection, protecting it from interception. PrestaShop sets this attribute when the store detects an HTTPS connection.

A common problem occurs with mixed HTTP/HTTPS configurations. If your back office is on HTTPS but some front office pages are on HTTP, cookies marked as Secure will not be sent on HTTP pages, breaking the session. The solution is to enforce HTTPS everywhere, which you should be doing anyway for security and SEO reasons.

HttpOnly Attribute

The HttpOnly attribute prevents JavaScript from accessing the cookie through document.cookie. This is a critical security measure against cross-site scripting (XSS) attacks. If an attacker injects malicious JavaScript into your store (through a vulnerable module, for example), the HttpOnly attribute prevents that code from stealing session cookies.

PrestaShop sets the HttpOnly flag on its cookies by default. Do not disable this unless you have a very specific reason and understand the security implications.

Debugging Session and Cookie Issues

Cookie and session problems manifest as mysterious symptoms: customers randomly logged out, carts that empty themselves, admin sessions that expire immediately, checkout processes that fail silently. Systematic debugging requires checking several layers.

Browser Developer Tools

Open the Application tab (Chrome) or Storage tab (Firefox) and navigate to Cookies. Find your store's domain and examine all cookies. Check the Name, Value, Domain, Path, Expires, Size, HttpOnly, Secure, and SameSite columns. Look for cookies that are unexpectedly large, that have incorrect domain settings (a cookie for www.example.com will not be sent to example.com), or that are missing security attributes.

Server-Side Session Verification

If sessions are stored in files, check the session directory for the presence and age of session files. If a customer reports being logged out, find their session file (the filename is the session ID from the PHPSESSID cookie) and check when it was last modified. If the file is missing, the session was either garbage collected or never created properly.

For Redis sessions, use redis-cli to check if the session key exists: EXISTS PHPREDIS_SESSION:session_id. Check the TTL to see if it is about to expire: TTL PHPREDIS_SESSION:session_id.

Common Causes of Random Logouts

The _COOKIE_KEY_ changed. If this key changes (during a misconfigured deployment, a settings file overwrite, or an upgrade), all existing cookies become unreadable because they were encrypted with the old key. Every customer is effectively logged out. The fix is to restore the original key from a backup.

Session garbage collection is too aggressive. PHP's session.gc_maxlifetime determines how long (in seconds) a session file is considered valid. If this is set too low (the default is 1440 seconds, or 24 minutes), sessions for customers who browse slowly are deleted. For a store, set this to at least 3600 (1 hour) or higher.

Load balancer without session affinity. If your store runs on multiple web servers behind a load balancer and sessions are stored in files, each server has its own session directory. A customer whose requests alternate between servers will lose their session on each switch. The solution is either session affinity (sticky sessions) on the load balancer, or shared session storage using Redis or a database.

Cookie domain mismatch. If your store is accessible at both www.example.com and example.com, but the cookie domain is set to www.example.com, customers who access the site without the www prefix will not have the cookie. Ensure consistent domain usage with a redirect and verify the cookie domain in PrestaShop's settings.

GDPR Cookie Compliance

The General Data Protection Regulation (GDPR) and the ePrivacy Directive require informed consent before setting non-essential cookies on a user's browser. PrestaShop stores must comply with these regulations, and failure to do so can result in significant fines.

Essential vs Non-Essential Cookies

GDPR distinguishes between cookies that are strictly necessary for the website to function and cookies that serve other purposes like analytics, marketing, or personalization. PrestaShop's session cookie is essential because the store cannot function without it. A customer cannot add products to a cart or complete a purchase without a session cookie. Essential cookies do not require consent under GDPR.

However, many other cookies commonly found on PrestaShop stores are non-essential and require explicit consent before being set. These include Google Analytics tracking cookies (_ga, _gid), Facebook Pixel cookies, advertising cookies from remarketing platforms, live chat widget cookies, social media sharing button cookies, and any cookies set by third-party modules for tracking or personalization purposes.

Implementing Cookie Consent

PrestaShop does not include a built-in cookie consent mechanism that meets GDPR requirements. You need either a PrestaShop module designed for cookie consent or integration with a third-party consent management platform (CMP) like Cookiebot, Osano, or Usercentrics.

A proper cookie consent implementation must present a clear choice to the user before any non-essential cookies are set. It must allow the user to accept or reject individual categories of cookies (analytics, marketing, etc.), not just offer an all-or-nothing choice. It must remember the user's choice and not ask again until the consent expires. It must actually prevent the blocked cookies from being set, not just record the preference while still loading tracking codes.

The last point is critical and often mishandled. A consent banner that shows up but loads Google Analytics anyway regardless of the user's choice provides no legal protection. The implementation must conditionally load tracking and marketing resources based on the user's consent.

Technical Implementation of Consent

The technical approach to consent-based cookie management involves wrapping non-essential code in consent checks. For inline JavaScript that sets cookies or loads tracking pixels, replace the direct execution with a consent-gated loader. The tracking code is stored but not executed until the user gives consent.

For third-party modules that set cookies, the implementation is more complex. Some modules provide hooks or configuration options for consent integration. Others load their cookies unconditionally and must be modified or replaced. Audit every module on your store for cookie usage and determine which ones set non-essential cookies.

Cookie Consent and Caching

Full-page caching creates a conflict with cookie consent. If a page is cached with Google Analytics loaded and served to a user who has not given consent, you are violating GDPR. There are two approaches to handle this.

The first approach is to cache the page without any non-essential resources and dynamically inject them via JavaScript after checking consent. This works well with PrestaShop's CCC (Combine, Compress, Cache) system and with Varnish or other reverse proxy caches.

The second approach is to not cache pages for users who have not yet made a consent choice (first-time visitors). This hurts performance for new visitors but ensures compliance. Most consent management platforms use the first approach because it preserves caching benefits.

Cookie-Related Security Concerns

Beyond the HttpOnly and Secure attributes already discussed, there are additional security considerations for PrestaShop cookies.

Cookie Theft and Session Hijacking

If an attacker obtains a valid PrestaShop session cookie, they can impersonate the customer or administrator. The primary protection is HTTPS everywhere (prevents interception), HttpOnly cookies (prevents XSS theft), and the Secure attribute (prevents transmission over HTTP). PrestaShop also binds sessions to IP addresses in some configurations, which provides an additional layer of protection but can cause problems for users whose IP addresses change (mobile users, VPN users).

Cookie Key Security

The _COOKIE_KEY_ in your PrestaShop configuration is the master key for cookie encryption. If this key is compromised, an attacker can decrypt any PrestaShop cookie and forge valid session cookies. Protect this key by restricting access to your configuration files, never committing it to public repositories, and never sharing it in support requests.

Cookie Fixation Prevention

Session fixation attacks involve an attacker setting a known session ID in a victim's browser before the victim logs in. When the victim logs in, the attacker's pre-set session ID becomes authenticated. PrestaShop mitigates this by regenerating the session ID upon login. Ensure that session ID regeneration is functioning correctly and has not been disabled by any module or configuration change.

Troubleshooting Common Cookie Problems

Admin Panel Login Loop

The symptom is entering valid credentials in the PrestaShop back office, briefly seeing the dashboard, and being redirected back to the login page. This is almost always a cookie problem. Check that the cookie domain is correct, that the admin directory name has not changed, that HTTPS is properly configured (mixed content can prevent the Secure cookie from being sent), and that the session storage directory is writable by the web server.

Cart Emptying on Page Navigation

If the cart empties when the customer navigates to another page, the session cookie is not being maintained. Common causes include a missing or incorrect cookie domain setting, a misconfigured session.cookie_lifetime in PHP (set to 0 means the cookie expires when the browser closes, which is correct, but some configurations set it to a very short time), or a CDN or caching layer that strips the Set-Cookie header from responses.

Checkout Failure After Payment

When customers complete payment but see an error or empty cart on the return to your store, the SameSite cookie policy is usually the cause, as described in the payment gateway section above. Test the full checkout flow with browser developer tools open, watching the cookies in each step to identify where the session is lost.

Multiple Stores on the Same Domain

If you run multiple PrestaShop installations on the same domain (for example, in subdirectories), their cookies can conflict. Each installation uses a similar cookie name, and if the cookie path is set to /, one store's cookie overwrites the other's. Set unique cookie names for each installation through the _COOKIE_KEY_ (which affects the cookie name) or configure the cookie path to match each installation's subdirectory.

Optimizing Cookie Configuration for Performance

A well-optimized PrestaShop cookie configuration minimizes overhead while maintaining functionality. Use a cookieless domain or CDN for static assets to avoid sending cookies with image, CSS, and JavaScript requests. Keep the cookie size small by preventing modules from storing unnecessary data in it. Set appropriate session timeouts that balance security (shorter is more secure) with user experience (longer means fewer re-logins). Use Redis for session storage to combine fast access with shared state across server instances. Enable the Secure and HttpOnly attributes to protect cookie integrity without affecting performance. Implement proper cookie consent to avoid loading unnecessary tracking cookies that add overhead and legal risk.

Each of these optimizations is small individually, but together they create a meaningful improvement in both performance and compliance. Cookie management is not glamorous work, but it underlies every interaction between your store and your customers, making it worth getting right.

For more details, read our guides: Cookie Consent for PrestaShop: What the Law Actually Requires and GDPR and Cookie Compliance for PrestaShop: What You Actually Need.