Problemas con las cookies en PrestaShop: Sesiones, RGPD y rendimiento

Cómo PrestaShop utiliza las cookies

Cada tienda PrestaShop depende de las cookies para funcionar. Mantienen las sesiones de los clientes, recuerdan el contenido del carrito, almacenan las preferencias de idioma y moneda, rastrean el estado de inicio de sesión y permiten al back office autenticar a los administradores. Sin cookies, una tienda PrestaShop no puede mantener el estado entre cargas de página, lo que significa que no hay carrito de compras, no hay inicio de sesión del cliente y no hay acceso al panel de administración.

PrestaShop utiliza dos cookies principales. La cookie del front office, típicamente nombrada según tu tienda (como PrestaShop-abc123), gestiona todo lo que necesita la parte orientada al cliente. La cookie del back office, con un patrón de nomenclatura similar pero un alcance diferente, gestiona la autenticación de los administradores. Ambas cookies almacenan datos serializados directamente en el valor de la cookie, una decisión de diseño que tiene implicaciones significativas para el rendimiento, la seguridad y el cumplimiento del RGPD.

Estructura y contenido de las cookies de PrestaShop

A diferencia de muchas aplicaciones web que almacenan solo un ID de sesión en la cookie y mantienen todos los datos de sesión en el servidor, PrestaShop almacena una cantidad sustancial de datos directamente en la propia cookie. La cookie del front office contiene campos que incluyen el ID del cliente, el nombre y correo electrónico del cliente, si el cliente está conectado, el ID del carrito, el idioma seleccionado, la moneda seleccionada, la última categoría visitada, el último producto visitado, el paso del proceso de compra y otra información de estado diversa.

Estos datos se serializan utilizando la clase de cookies propia de PrestaShop (Cookie.php en el directorio classes). El valor de la cookie se cifra utilizando una clave derivada de la constante _COOKIE_KEY_ en config/settings.inc.php (PrestaShop 1.6/1.7) o app/config/parameters.php (PrestaShop 8.x). Este cifrado previene la manipulación y protege datos sensibles como el ID del cliente y el correo electrónico de ser legibles en el navegador.

Por qué PrestaShop almacena datos en la cookie

La razón histórica de esta decisión de diseño es el rendimiento. Al almacenar datos de sesión en la cookie, PrestaShop evita una búsqueda de sesión del lado del servidor en cada solicitud. No hay necesidad de leer un archivo de sesión, consultar una base de datos ni conectarse a un servidor de sesiones. Los datos llegan con la solicitud, ya disponibles.

Sin embargo, este enfoque tiene desventajas que se vuelven más relevantes a medida que la tienda crece. El tamaño de la cookie aumenta con la cantidad de datos almacenados, y cada solicitud HTTP (incluyendo solicitudes de imágenes, CSS y archivos JavaScript) envía la cookie completa al servidor. Una cookie de 4 KB enviada con 30 solicitudes de recursos por carga de página significa 120 KB de ancho de banda de subida innecesario por carga de página. Esta sobrecarga es medible en conexiones móviles y a gran escala.

Tamaño de la cookie e impacto en el rendimiento

Las cookies del navegador tienen un límite práctico de tamaño de aproximadamente 4.096 bytes por cookie. La cookie del front office de PrestaShop puede acercarse o superar este límite, especialmente cuando los módulos añaden sus propios datos a la cookie a través de hookActionBeforeSubmitAccount o modificando directamente el objeto cookie.

Midiendo el impacto del tamaño de la cookie

Para ver cómo las cookies afectan al rendimiento de tu tienda, abre las herramientas de desarrollador del navegador y ve a la pestaña Red. Observa las cabeceras de solicitud de cualquier petición a tu dominio. La cabecera Cookie muestra todas las cookies enviadas. Fíjate en su tamaño. Ahora observa las cabeceras de solicitud de un recurso estático (una imagen o archivo CSS) en el mismo dominio. Las mismas cookies se envían con esa solicitud también, añadiendo sobrecarga sin razón.

Reduciendo la sobrecarga de cookies para recursos estáticos

La forma más efectiva de eliminar la sobrecarga de cookies para archivos estáticos es servirlos desde un dominio diferente (un dominio sin cookies). En PrestaShop, puedes configurar servidores de medios en el back office en Parámetros avanzados > Rendimiento. Cuando configuras un servidor de medios como static.tudominio.com, PrestaShop sirve imágenes, CSS y JavaScript desde ese dominio. Como las cookies son específicas del dominio, ninguna cookie se envía con las solicitudes al dominio de medios.

Alternativamente, un CDN como Cloudflare, Fastly o CloudFront puede servir tus recursos estáticos. Los servidores de borde del CDN típicamente eliminan las cookies de las respuestas en caché, por lo que aunque las cookies se envíen en la solicitud, la respuesta viene de la caché sin la sobrecarga de un viaje de ida y vuelta al servidor de origen.

Inflado de cookies por módulos

Los módulos de terceros a veces añaden datos a la cookie de PrestaShop sin considerar las implicaciones de tamaño. Cada módulo que almacena un valor en la cookie aumenta su tamaño y la sobrecarga en cada solicitud. Si tu cookie es inusualmente grande, verifica qué datos han añadido los módulos examinando el contenido descifrado de la cookie o revisando el código de los módulos en busca de llamadas a $this->context->cookie->mymodule_value = ....

Los módulos bien diseñados usan almacenamiento del lado del servidor (base de datos o caché) y almacenan como máximo un pequeño identificador en la cookie. Los módulos mal diseñados vuelcan estructuras de datos completas en la cookie, inflando su tamaño. Si identificas un módulo problemático, contacta al desarrollador o reemplaza el almacenamiento en cookie por almacenamiento respaldado por base de datos usando un identificador de sesión.

Gestión de sesiones: archivos, base de datos y Redis

Mientras PrestaShop almacena algunos datos directamente en cookies, PHP también mantiene su propio sistema de sesiones. El back office de PrestaShop depende más intensamente de las sesiones PHP que el front office. El gestor de sesiones determina dónde se almacenan los datos de sesión en el lado del servidor.

Sesiones basadas en archivos (predeterminadas)

Por defecto, PHP almacena las sesiones como archivos en el directorio session.save_path (típicamente /tmp o /var/lib/php/sessions). Cada sesión crea un archivo. Para una tienda con miles de sesiones activas, esto significa miles de archivos pequeños. Las sesiones basadas en archivos funcionan bien para tiendas pequeñas y medianas pero pueden causar problemas a gran escala.

Los problemas comunes con las sesiones basadas en archivos incluyen la recolección de basura lenta cuando el directorio de sesiones contiene demasiados archivos, el bloqueo de archivos que puede causar la serialización de solicitudes (dos solicitudes de la misma sesión no pueden procesarse simultáneamente) y los entornos de alojamiento compartido donde el directorio de sesiones se llena o tiene permisos restrictivos.

Sesiones en base de datos

PrestaShop soporta almacenar sesiones en la base de datos. Esto se configura en los ajustes de PHP o a través del gestor de sesiones de PrestaShop. Las sesiones en base de datos eliminan los problemas del sistema de archivos pero añaden una consulta a la base de datos por cada solicitud. Para tiendas que ya tienen una carga alta de base de datos, esto puede empeorar el rendimiento. Sin embargo, las sesiones en base de datos tienen la ventaja de ser compartidas entre múltiples servidores web en una configuración con balanceo de carga.

Sesiones con Redis o Memcached

Para tiendas PrestaShop de alto tráfico, Redis es el backend óptimo para el almacenamiento de sesiones. Redis almacena los datos de sesión en memoria, proporcionando tiempos de acceso inferiores al milisegundo. Soporta la expiración automática (timeout de sesión) y los datos de sesión se comparten entre todas las instancias del servidor web.

Para configurar PHP para usar Redis para las sesiones, establece session.save_handler = redis y session.save_path = "tcp://127.0.0.1:6379" en tu archivo php.ini o en la configuración del pool de PHP-FPM. Si tu instancia de Redis requiere autenticación, añade la contraseña a la ruta de guardado: "tcp://127.0.0.1:6379?auth=tucontraseña".

PrestaShop ya soporta Redis para el caché de objetos (configurado en el back office en Parámetros avanzados > Rendimiento). Usar la misma instancia de Redis tanto para sesiones como para caché de objetos simplifica tu infraestructura proporcionando al mismo tiempo un rendimiento excelente para ambos.

Atributos SameSite, Secure y HttpOnly

Los navegadores modernos aplican atributos de seguridad de cookies que afectan directamente al comportamiento de las cookies de PrestaShop. Los atributos de cookie mal configurados causan errores de inicio de sesión, carritos perdidos y errores en el procesamiento de pagos.

Atributo SameSite

El atributo SameSite controla si una cookie se envía con solicitudes entre sitios. Tiene tres valores posibles:

SameSite=Strict significa que la cookie nunca se envía con solicitudes entre sitios. Esto es demasiado restrictivo para PrestaShop porque los clientes que hacen clic en un enlace a tu tienda desde un correo electrónico o redes sociales no tendrían su cookie de sesión enviada, desconectándoles efectivamente.

SameSite=Lax es el valor predeterminado en los navegadores modernos. La cookie se envía con navegaciones de nivel superior (hacer clic en un enlace) pero no con sub-solicitudes entre sitios (imágenes, iframes, AJAX). Esto funciona bien para la cookie del front office de PrestaShop en la mayoría de los casos.

SameSite=None significa que la cookie siempre se envía, incluyendo con solicitudes entre sitios. Debe ir acompañada del atributo Secure. Se necesita cuando tu tienda está incrustada en un iframe en otro sitio o cuando las pasarelas de pago de terceros necesitan redirigir de vuelta a tu tienda con la sesión intacta.

Problemas con las pasarelas de pago

Muchos problemas de pago en PrestaShop son causados por problemas con las cookies SameSite. El escenario típico es: un cliente procede al pago, es redirigido al sitio de la pasarela de pago, completa el pago y es redirigido de vuelta a tu tienda. Si la cookie de sesión tiene SameSite=Lax, puede no enviarse en la redirección desde la pasarela de pago, dependiendo de cómo se implemente la redirección. Si la pasarela usa una redirección POST (común con 3D Secure), la política Lax bloquea la cookie y PrestaShop pierde la sesión. El cliente ve un carrito vacío o una página de error genérica en lugar de la confirmación del pedido.

La solución es configurar la cookie de PrestaShop como SameSite=None; Secure. En PrestaShop 1.7.7+ y 8.x, esto se puede configurar en los ajustes de cookies. Para versiones anteriores, puede ser necesario modificar la clase Cookie o añadir cabeceras a través de la configuración del servidor web. Siempre prueba los flujos de pago después de cambiar los ajustes de SameSite.

Atributo Secure

El atributo Secure asegura que la cookie solo se envía a través de conexiones HTTPS. Si tu tienda funciona sobre HTTPS (como debería), este atributo previene que la cookie sea transmitida a través de una conexión no cifrada, protegiéndola de la interceptación. PrestaShop establece este atributo cuando la tienda detecta una conexión HTTPS.

Un problema común ocurre con configuraciones mixtas HTTP/HTTPS. Si tu back office está en HTTPS pero algunas páginas del front office están en HTTP, las cookies marcadas como Secure no se enviarán en las páginas HTTP, rompiendo la sesión. La solución es forzar HTTPS en todas partes, lo cual deberías hacer de todos modos por razones de seguridad y SEO.

Atributo HttpOnly

El atributo HttpOnly impide que JavaScript acceda a la cookie a través de document.cookie. Esta es una medida de seguridad crítica contra ataques de cross-site scripting (XSS). Si un atacante inyecta JavaScript malicioso en tu tienda (a través de un módulo vulnerable, por ejemplo), el atributo HttpOnly impide que ese código robe las cookies de sesión.

PrestaShop establece el flag HttpOnly en sus cookies por defecto. No lo desactives a menos que tengas una razón muy específica y entiendas las implicaciones de seguridad.

Depuración de problemas de sesión y cookies

Los problemas de cookies y sesiones se manifiestan como síntomas misteriosos: clientes desconectados aleatoriamente, carritos que se vacían solos, sesiones de administración que expiran inmediatamente, procesos de pago que fallan silenciosamente. La depuración sistemática requiere verificar varias capas.

Herramientas de desarrollador del navegador

Abre la pestaña Application (Chrome) o Storage (Firefox) y navega a Cookies. Encuentra el dominio de tu tienda y examina todas las cookies. Verifica las columnas Nombre, Valor, Dominio, Ruta, Expira, Tamaño, HttpOnly, Secure y SameSite. Busca cookies que sean inusualmente grandes, que tengan configuraciones de dominio incorrectas (una cookie para www.example.com no se enviará a example.com) o que les falten atributos de seguridad.

Verificación de sesiones del lado del servidor

Si las sesiones se almacenan en archivos, verifica el directorio de sesiones en busca de la presencia y antigüedad de los archivos de sesión. Si un cliente reporta haber sido desconectado, encuentra su archivo de sesión (el nombre del archivo es el ID de sesión de la cookie PHPSESSID) y verifica cuándo fue modificado por última vez. Si el archivo falta, la sesión fue recolectada por el recolector de basura o nunca se creó correctamente.

Para sesiones en Redis, usa redis-cli para verificar si la clave de sesión existe: EXISTS PHPREDIS_SESSION:session_id. Verifica el TTL para ver si está a punto de expirar: TTL PHPREDIS_SESSION:session_id.

Causas comunes de desconexiones aleatorias

El _COOKIE_KEY_ cambió. Si esta clave cambia (durante un despliegue mal configurado, una sobrescritura del archivo de configuración o una actualización), todas las cookies existentes se vuelven ilegibles porque fueron cifradas con la clave antigua. Todos los clientes quedan efectivamente desconectados. La solución es restaurar la clave original desde una copia de seguridad.

La recolección de basura de sesiones es demasiado agresiva. El parámetro PHP session.gc_maxlifetime determina cuánto tiempo (en segundos) un archivo de sesión se considera válido. Si esto está configurado demasiado bajo (el valor predeterminado es 1440 segundos, o 24 minutos), las sesiones de los clientes que navegan lentamente se eliminan. Para una tienda, configúralo a al menos 3600 (1 hora) o más.

Balanceador de carga sin afinidad de sesión. Si tu tienda funciona en múltiples servidores web detrás de un balanceador de carga y las sesiones se almacenan en archivos, cada servidor tiene su propio directorio de sesiones. Un cliente cuyas solicitudes alternan entre servidores perderá su sesión en cada cambio. La solución es la afinidad de sesión (sesiones pegajosas) en el balanceador de carga, o almacenamiento de sesiones compartido usando Redis o una base de datos.

Discordancia del dominio de la cookie. Si tu tienda es accesible tanto en www.example.com como en example.com, pero el dominio de la cookie está configurado como www.example.com, los clientes que accedan al sitio sin el prefijo www no tendrán la cookie. Asegura un uso consistente del dominio con una redirección y verifica el dominio de la cookie en la configuración de PrestaShop.

Cumplimiento de cookies con el RGPD

El Reglamento General de Protección de Datos (RGPD) y la Directiva ePrivacy requieren consentimiento informado antes de establecer cookies no esenciales en el navegador del usuario. Las tiendas PrestaShop deben cumplir con estas regulaciones, y el incumplimiento puede resultar en sanciones significativas.

Cookies esenciales vs no esenciales

El RGPD distingue entre cookies estrictamente necesarias para el funcionamiento del sitio web y cookies que sirven para otros propósitos como analítica, marketing o personalización. La cookie de sesión de PrestaShop es esencial porque la tienda no puede funcionar sin ella. Un cliente no puede añadir productos al carrito ni completar una compra sin una cookie de sesión. Las cookies esenciales no requieren consentimiento bajo el RGPD.

Sin embargo, muchas otras cookies comúnmente encontradas en tiendas PrestaShop son no esenciales y requieren consentimiento explícito antes de ser establecidas. Estas incluyen las cookies de seguimiento de Google Analytics (_ga, _gid), las cookies del Facebook Pixel, las cookies publicitarias de plataformas de remarketing, las cookies de widgets de chat en vivo, las cookies de botones para compartir en redes sociales y cualquier cookie establecida por módulos de terceros con fines de seguimiento o personalización.

Implementación del consentimiento de cookies

PrestaShop no incluye un mecanismo integrado de consentimiento de cookies que cumpla los requisitos del RGPD. Necesitas un módulo de PrestaShop diseñado para el consentimiento de cookies o la integración con una plataforma de gestión del consentimiento (CMP) de terceros como Cookiebot, Osano o Usercentrics.

Una implementación adecuada del consentimiento de cookies debe presentar al usuario una elección clara antes de que se establezca cualquier cookie no esencial. Debe permitir al usuario aceptar o rechazar categorías individuales de cookies (analítica, marketing, etc.), no solo ofrecer una elección de todo-o-nada. Debe recordar la elección del usuario y no preguntar de nuevo hasta que expire el consentimiento. Debe realmente prevenir que las cookies bloqueadas se establezcan, no solo registrar la preferencia mientras sigue cargando los códigos de seguimiento.

El último punto es crítico y a menudo mal gestionado. Un banner de consentimiento que aparece pero carga Google Analytics de todos modos independientemente de la elección del usuario no proporciona ninguna protección legal. La implementación debe cargar condicionalmente los recursos de seguimiento y marketing basándose en el consentimiento del usuario.

Implementación técnica del consentimiento

El enfoque técnico para la gestión de cookies basada en consentimiento implica envolver el código no esencial en verificaciones de consentimiento. Para el JavaScript en línea que establece cookies o carga píxeles de seguimiento, reemplaza la ejecución directa con un cargador condicionado al consentimiento. El código de seguimiento se almacena pero no se ejecuta hasta que el usuario da su consentimiento.

Para los módulos de terceros que establecen cookies, la implementación es más compleja. Algunos módulos proporcionan hooks u opciones de configuración para la integración del consentimiento. Otros cargan sus cookies incondicionalmente y deben ser modificados o reemplazados. Audita cada módulo en tu tienda respecto al uso de cookies y determina cuáles establecen cookies no esenciales.

Consentimiento de cookies y almacenamiento en caché

El almacenamiento en caché de página completa crea un conflicto con el consentimiento de cookies. Si una página se almacena en caché con Google Analytics cargado y se sirve a un usuario que no ha dado consentimiento, estás violando el RGPD. Hay dos enfoques para manejar esto.

El primer enfoque es almacenar en caché la página sin recursos no esenciales e inyectarlos dinámicamente mediante JavaScript después de verificar el consentimiento. Esto funciona bien con el sistema CCC (Combine, Compress, Cache) de PrestaShop y con Varnish u otras cachés de proxy inverso.

El segundo enfoque es no almacenar en caché las páginas para usuarios que aún no han hecho una elección de consentimiento (visitantes por primera vez). Esto perjudica el rendimiento para nuevos visitantes pero asegura el cumplimiento. La mayoría de las plataformas de gestión del consentimiento utilizan el primer enfoque porque preserva los beneficios del almacenamiento en caché.

Consideraciones de seguridad relacionadas con las cookies

Más allá de los atributos HttpOnly y Secure ya discutidos, hay consideraciones de seguridad adicionales para las cookies de PrestaShop.

Robo de cookies y secuestro de sesión

Si un atacante obtiene una cookie de sesión válida de PrestaShop, puede suplantar al cliente o al administrador. La protección principal es HTTPS en todas partes (previene la interceptación), cookies HttpOnly (previene el robo por XSS) y el atributo Secure (previene la transmisión por HTTP). PrestaShop también vincula las sesiones a las direcciones IP en algunas configuraciones, lo que proporciona una capa adicional de protección pero puede causar problemas a los usuarios cuyas direcciones IP cambian (usuarios móviles, usuarios de VPN).

Seguridad de la clave de la cookie

El _COOKIE_KEY_ en la configuración de PrestaShop es la clave maestra para el cifrado de cookies. Si esta clave se ve comprometida, un atacante puede descifrar cualquier cookie de PrestaShop y falsificar cookies de sesión válidas. Protege esta clave restringiendo el acceso a los archivos de configuración, nunca commitándola en repositorios públicos y nunca compartiéndola en solicitudes de soporte.

Prevención de la fijación de sesión

Los ataques de fijación de sesión implican que un atacante establece un ID de sesión conocido en el navegador de la víctima antes de que la víctima inicie sesión. Cuando la víctima inicia sesión, el ID de sesión preestablecido por el atacante se convierte en autenticado. PrestaShop mitiga esto regenerando el ID de sesión al iniciar sesión. Asegúrate de que la regeneración del ID de sesión funcione correctamente y no haya sido deshabilitada por ningún módulo o cambio de configuración.

Resolución de problemas comunes con las cookies

Bucle de inicio de sesión en el panel de administración

El síntoma es introducir credenciales válidas en el back office de PrestaShop, ver brevemente el panel de control y ser redirigido de vuelta a la página de inicio de sesión. Esto es casi siempre un problema de cookies. Verifica que el dominio de la cookie sea correcto, que el nombre del directorio de administración no haya cambiado, que HTTPS esté correctamente configurado (el contenido mixto puede impedir el envío de la cookie Secure) y que el directorio de almacenamiento de sesiones sea escribible por el servidor web.

Carrito que se vacía al navegar

Si el carrito se vacía cuando el cliente navega a otra página, la cookie de sesión no se está manteniendo. Las causas comunes incluyen una configuración del dominio de la cookie faltante o incorrecta, un session.cookie_lifetime mal configurado en PHP (establecido en 0 significa que la cookie expira al cerrar el navegador, lo cual es correcto, pero algunas configuraciones lo establecen en un tiempo muy corto), o una capa de CDN o almacenamiento en caché que elimina la cabecera Set-Cookie de las respuestas.

Fallo del pago después del proceso de pago

Cuando los clientes completan el pago pero ven un error o un carrito vacío al regresar a tu tienda, la política SameSite de la cookie suele ser la causa, como se describió en la sección de pasarelas de pago anterior. Prueba el flujo completo de pago con las herramientas de desarrollador del navegador abiertas, observando las cookies en cada paso para identificar dónde se pierde la sesión.

Múltiples tiendas en el mismo dominio

Si ejecutas múltiples instalaciones de PrestaShop en el mismo dominio (por ejemplo, en subdirectorios), sus cookies pueden entrar en conflicto. Cada instalación usa un nombre de cookie similar, y si la ruta de la cookie está establecida en /, la cookie de una tienda sobrescribe la de la otra. Establece nombres de cookie únicos para cada instalación a través del _COOKIE_KEY_ (que afecta al nombre de la cookie) o configura la ruta de la cookie para que coincida con el subdirectorio de cada instalación.

Optimización de la configuración de cookies para el rendimiento

Una configuración de cookies de PrestaShop bien optimizada minimiza la sobrecarga mientras mantiene la funcionalidad. Usa un dominio sin cookies o un CDN para los recursos estáticos para evitar enviar cookies con solicitudes de imágenes, CSS y JavaScript. Mantén el tamaño de la cookie pequeño evitando que los módulos almacenen datos innecesarios en ella. Establece tiempos de espera de sesión apropiados que equilibren la seguridad (más corto es más seguro) con la experiencia del usuario (más largo significa menos re-inicios de sesión). Usa Redis para el almacenamiento de sesiones para combinar acceso rápido con estado compartido entre instancias del servidor. Habilita los atributos Secure y HttpOnly para proteger la integridad de la cookie sin afectar al rendimiento. Implementa un consentimiento de cookies adecuado para evitar cargar cookies de seguimiento innecesarias que añaden sobrecarga y riesgo legal.

Cada una de estas optimizaciones es individualmente pequeña, pero juntas crean una mejora significativa tanto en rendimiento como en cumplimiento. La gestión de cookies no es un trabajo glamuroso, pero subyace a cada interacción entre tu tienda y tus clientes, lo que hace que valga la pena hacerlo bien.