CONCEPTOS BASE

Cookie

Dato pequeño que un sitio guarda en tu navegador y le devuelves en cada visita. Sirve para recordarte, y por eso está regulada.

Nivel · principiante4 min de lecturaActualizado 28 ago 2026
También conocido como: Galleta, Cookie HTTP

Definición

Una cookie es un dato pequeño que un sitio web pide al navegador que guarde, y que el navegador le devuelve automáticamente en cada petición siguiente.

Existe por una limitación de origen: HTTP no recuerda nada. Cada petición es independiente y el servidor no sabe si quien pregunta es el mismo de hace un segundo. La cookie es el mecanismo que permite reconocerte entre una página y la siguiente.

Los atributos que importan

Una cookie mal configurada es un agujero de seguridad. Cuatro atributos deciden casi todo:

HttpOnly. El JavaScript de la página no puede leerla. Es lo que impide que un ataque XSS robe la cookie de sesión. Toda cookie de sesión debería tenerlo.

Secure. Solo se envía por HTTPS. Sin esto, viaja en claro por redes que no controlas.

SameSite. Controla si se envía en peticiones que vienen de otro sitio. Es la defensa principal contra CSRF:

  • Strict: nunca en peticiones externas. Muy seguro y a veces incómodo — si llegas desde un enlace externo, apareces sin sesión.
  • Lax: valor por defecto en los navegadores modernos. Se envía al navegar, no en peticiones en segundo plano.
  • None: se envía siempre, y exige Secure.

Expiración. Sin fecha, dura lo que la ventana del navegador. Con fecha, persiste.

Ese Lax por defecto es fuente de sorpresas: flujos que funcionaban dejaron de hacerlo cuando los navegadores lo cambiaron, especialmente en retornos desde pasarelas de pago o desde procesos de autorización externos.

Lo que exige la normativa española

Aquí es donde muchos proyectos incumplen sin saberlo. La distinción clave:

Cookies técnicas o necesarias. Las imprescindibles para que el servicio funcione: mantener la sesión, recordar el idioma, el carrito. No requieren consentimiento, aunque sí informar.

El resto —analítica, publicidad, personalización, cualquier cookie de terceros— requiere consentimiento previo, informado y expreso.

Y con condiciones concretas: no se pueden instalar antes de que el usuario acepte, rechazar debe ser tan fácil como aceptar, y seguir navegando no es consentimiento. Los banners que solo tienen un botón «Aceptar» llevan años siendo motivo de sanción.

Ejemplo práctico

Lo que aprendí montando esto: la decisión más limpia es no necesitar consentimiento. Si un sitio no usa analítica de terceros ni publicidad, y solo pone las cookies técnicas imprescindibles, no hace falta banner — basta con informar en la política de cookies.

Eso no es solo comodidad legal. Un sitio sin banner carga más rápido, no interrumpe al visitante y puede afirmar con verdad que no lo rastrea. Es una decisión de producto, no solo de cumplimiento.

Cuando hace falta medir, hay analíticas que funcionan sin cookies: identificando la visita en el servidor con un dato que se renueva a diario y no permite seguir a nadie entre días. Se pierde precisión y se gana no tener que pedir permiso para nada.

El segundo aprendizaje, técnico y caro de depurar: SameSite=Lax rompe flujos que vuelven de un sitio externo. Un proceso de autorización bancaria que redirige de vuelta a tu web puede llegar sin la cookie de estado, y el usuario aparece como si no hubiera empezado nada. El síntoma es desconcertante —«a veces funciona y a veces no»— y la causa es el navegador haciendo lo correcto.

La solución no es poner None a todo: es entender qué cookie hace falta en ese retorno concreto y configurarla en consecuencia.

Errores comunes

  • Cookie de sesión sin HttpOnly. Un XSS se la lleva.
  • Sin Secure en un sitio con HTTPS.
  • No entender SameSite hasta que un flujo se rompe.
  • Guardar datos sensibles en la cookie. Solo debería ir un identificador.
  • Banner con «Aceptar» y sin «Rechazar» igual de accesible.
  • Instalar cookies antes del consentimiento.
  • Confundir cookies con localStorage. Este último no se envía al servidor solo, pero sí es accesible por JavaScript.

Cuándo revisarlo

Al montar cualquier sistema de autenticación, al integrar un servicio externo que redirige de vuelta, y en cualquier revisión legal del sitio.

La comprobación rápida: abre las herramientas de desarrollo, mira tus cookies y pregúntate por cada una si es imprescindible y si tiene los atributos correctos. Suele haber sorpresas.

Referencias

Tagsprogramacionwebseguridadconceptos-base
Escrito por
Antonio Echeverría

Dirijo IMDICA, una empresa de suministro industrial, desde 2007. Escribo estas definiciones desde el lado de quien las usa para decidir, no desde el de quien las estudia.

Si necesitas que alguien construya esto de verdad y no solo lo explique, eso es lo que hago en AE Works.