¿Qué es una cookie?
Una cookie HTTP es un pequeño fragmento de datos que un sitio web hace guardar en el navegador y que el navegador puede devolver automáticamente en solicitudes posteriores cuando coinciden las reglas de alcance de esa cookie. Permite mantener estado sobre HTTP —por ejemplo, una sesión, una preferencia o un identificador— y puede ser de sesión o persistente, y de primera o tercera parte según el contexto en el que se utiliza. No equivale a tracking ni a consentimiento: una cookie puede cumplir una función necesaria sin rastrear a una persona, y el tracking también puede realizarse mediante otras tecnologías; las obligaciones de información o consentimiento dependen del propósito, la tecnología y la normativa aplicable.
- ¿Qué es una cookie?
- Cómo funciona una cookie HTTP
- Qué información define una cookie
- Para qué se utilizan
- Cookies de sesión vs. persistentes
- First-party vs. third-party cookies
- SameSite y cookies cross-site
- Secure, HttpOnly y seguridad
- Cookies particionadas
- Cookie vs. tracking
- Cookie vs. localStorage
- Cookies y consentimiento
- Errores frecuentes
- Ejemplo práctico
- Preguntas frecuentes
- Referencias clave
¿Qué es una cookie?
HTTP fue diseñado como un protocolo esencialmente sin estado: una solicitud no necesita recordar automáticamente lo que ocurrió en la anterior. Las cookies agregan un mecanismo para conservar pequeñas piezas de estado entre solicitudes.
El estándar RFC 6265 define los encabezados Set-Cookie y Cookie. Un servidor puede enviar Set-Cookie en una respuesta y, cuando corresponde, el navegador almacena esa cookie y la devuelve después mediante el encabezado Cookie. Algunas cookies también pueden crearse o modificarse desde JavaScript cuando sus atributos lo permiten.
La cookie no tiene por qué contener toda la información de una sesión. De hecho, es habitual que guarde un identificador opaco y que los datos importantes permanezcan del lado del servidor.
Cómo funciona una cookie HTTP
Se crea
El servidor envía una instrucción Set-Cookie o, en ciertos casos, el sitio la crea mediante una API del navegador.
El navegador la guarda
Conserva el nombre, valor y metadatos que determinan alcance, duración y condiciones de envío.
Evalúa el alcance
Antes de una solicitud, el navegador revisa dominio o host, path, seguridad, contexto same-site/cross-site, expiración y otras restricciones.
La devuelve cuando corresponde
Las cookies que cumplen las condiciones se incluyen automáticamente en la solicitud HTTP al servidor.
El servidor utiliza el estado
Puede reconocer una sesión, recuperar un carrito, recordar una preferencia o asociar la solicitud con un identificador de medición.
Qué información define una cookie
Una cookie tiene un nombre y un valor, pero el encabezado que la establece puede incluir atributos que controlan cómo se comporta. Los más habituales son:
Domain
Define qué dominio puede recibirla. Si no se especifica, queda limitada al host que la estableció.
Path
Limita las rutas dentro del host en las que el navegador puede enviarla.
Expires / Max-Age
Determinan cuánto tiempo puede persistir antes de expirar.
Secure
Hace que la cookie se envíe únicamente mediante conexiones HTTPS, con la excepción especial de localhost en algunos navegadores.
HttpOnly
Impide el acceso desde JavaScript y es especialmente importante para proteger identificadores de sesión frente a ciertos ataques XSS.
SameSite
Controla en qué contextos cross-site puede enviarse y ayuda a reducir ciertos riesgos como CSRF.
Partitioned
Permite almacenar una cookie en una partición asociada al sitio de nivel superior, reduciendo su capacidad de funcionar como identificador compartido entre sitios.
Estos atributos no convierten automáticamente una cookie en “segura” o “privada”. Cada uno resuelve una parte distinta del comportamiento y debe configurarse según el propósito.
Para qué se utilizan las cookies
Las cookies tienen usos muy distintos. Reducirlas a publicidad o tracking genera una definición incorrecta.
Sesión y autenticación
Mantener una sesión iniciada o asociar solicitudes con una sesión ya autenticada.
Estado de una operación
Recordar un carrito, una selección temporal o un paso de un flujo.
Preferencias
Idioma, configuración visual u otras elecciones que conviene conservar.
Seguridad
Contribuir a controles antifraude, protección de sesión o mecanismos técnicos de seguridad.
Medición
Asociar eventos o visitas a un identificador para producir métricas de uso.
Publicidad y personalización
Reconocer contextos o audiencias para frecuencia, atribución, personalización u otros usos publicitarios cuando la tecnología y las reglas aplicables lo permiten.
Cookies de sesión vs. cookies persistentes
Una cookie de sesión no tiene una fecha o duración persistente definida mediante Expires o Max-Age. En condiciones normales se elimina al terminar la sesión del navegador, aunque funciones como la restauración de sesión pueden modificar lo que una persona percibe como “cerrar y volver a abrir”.
Una cookie persistente sí tiene una duración. Permanece hasta su vencimiento, hasta que el navegador o la persona la elimina, o hasta que alguna política del navegador limita su vida efectiva.
La distinción describe duración, no propósito. Tanto una cookie de sesión como una persistente pueden ser funcionales, de seguridad, analíticas o cumplir otros usos.
First-party vs. third-party cookies
La diferencia se entiende mejor como same-site vs. cross-site que como una clasificación de empresas. MDN explica que una cookie es first-party cuando el site asociado coincide con el site que la persona está visitando; si pertenece a un site diferente dentro de ese contexto, se considera third-party o cross-site.
Por ejemplo, una página puede cargar un iframe, un widget, una imagen o código desde otro site. Si ese contexto externo utiliza cookies, esas cookies pueden operar como third-party respecto de la página principal.
Una third-party cookie no es automáticamente publicitaria y una first-party cookie no es automáticamente inocua desde el punto de vista de privacidad. Lo importante es qué información se almacena o accede, con qué propósito y cómo se utiliza.
SameSite y cookies cross-site
El atributo SameSite limita cuándo una cookie puede acompañar solicitudes originadas en otros sitios. Sus valores principales son Strict, Lax y None.
Strict es el modo más restrictivo. Lax permite algunos contextos de navegación de nivel superior. None permite contextos cross-site y requiere además Secure.
SameSite tiene efectos tanto de seguridad como de privacidad, pero no debe interpretarse como un sistema completo de consentimiento ni como una garantía de que una cookie pueda utilizarse legítimamente para cualquier propósito.
Secure, HttpOnly y seguridad de cookies
Secure hace que la cookie se transmita únicamente por HTTPS. HttpOnly evita que JavaScript acceda a ella mediante APIs como document.cookie. Combinados con un alcance restrictivo y una expiración apropiada, son controles fundamentales para cookies de sesión.
Sin embargo, una cookie no debería utilizarse como caja fuerte para almacenar información confidencial en texto legible. Una práctica habitual es guardar un identificador de sesión difícil de adivinar y mantener los datos sensibles en sistemas del servidor.
Cookies particionadas
Los navegadores modernos también admiten cookies particionadas. Con el atributo Partitioned, el almacenamiento queda separado según el sitio de nivel superior desde el que se utiliza el contexto embebido.
Esto permite ciertos casos legítimos de contenido de terceros sin entregar necesariamente un mismo identificador compartido entre todos los sitios donde aparece ese tercero. Las cookies particionadas requieren Secure en la implementación documentada por MDN.
Cookie vs. tracking
Una cookie es un mecanismo de almacenamiento y devolución de estado. El tracking es el proceso de registrar o relacionar interacciones, eventos o identificadores a lo largo del tiempo.
Una cookie puede participar en tracking si su identificador permite reconocer actividad entre visitas o contextos. Pero también puede existir sin ningún objetivo de seguimiento, por ejemplo para conservar una sesión autenticada o un carrito.
Y el tracking no necesita necesariamente cookies. Puede apoyarse en almacenamiento local, parámetros de URL, identificadores de cuenta, server-side tracking, píxeles, SDK o técnicas de fingerprinting. Por eso “cookie-less” no significa automáticamente “sin tracking”.
Cookie vs. localStorage
localStorage es otra forma de almacenamiento del navegador, pero no forma parte del mecanismo de encabezados HTTP de cookies.
La diferencia práctica más importante es que una cookie que coincide con su alcance puede ser enviada automáticamente por el navegador en solicitudes HTTP. Un valor de localStorage permanece en el navegador hasta que el código lo lee y decide qué hacer con él.
Eso hace que no sean sustitutos perfectos. Para una sesión de servidor, la semántica de cookie puede ser especialmente útil; para datos puramente locales de una interfaz, otro almacenamiento puede ser más apropiado.
Cookies y consentimiento
Que una tecnología sea una cookie no determina por sí solo si necesita consentimiento. Las obligaciones dependen de la jurisdicción, del propósito y del tipo de acceso o almacenamiento.
Por ejemplo, la normativa británica PECR exige normalmente información y consentimiento para cookies y tecnologías similares, pero contempla excepciones para usos estrictamente necesarios para prestar un servicio solicitado por la persona. El ICO incluye entre los ejemplos ciertos usos de autenticación, seguridad, carrito o balanceo de carga.
Otros marcos pueden establecer reglas diferentes. Además, las normas suelen alcanzar tecnologías distintas de las cookies cuando almacenan o acceden a información en el dispositivo. Por eso la clasificación first-party/third-party no debería utilizarse como atajo para decidir cumplimiento.
La gestión de consentimiento es el proceso con el que una organización captura, registra, transmite y aplica las decisiones que correspondan. El banner es solo una interfaz dentro de ese proceso.
Errores frecuentes al hablar de cookies
“Todas las cookies rastrean personas”. Falso. Muchas existen para sesión, carrito, seguridad o preferencias.
“Las cookies son archivos que un sitio instala”. Es una simplificación útil para usuarios, pero técnicamente conviene hablar de datos que el navegador almacena y gestiona según reglas de HTTP.
“First-party significa propia y third-party significa de otra empresa”. La distinción técnica depende del contexto del site, no solamente de propiedad corporativa.
“Borrar cookies elimina todo el tracking”. Falso. Existen otras formas de almacenamiento e identificación.
“SameSite=None significa sin privacidad”. No. El atributo controla envío cross-site; la privacidad depende del propósito, los datos y el ecosistema completo.
“Si una cookie es first-party no necesita consentimiento”. No es una regla universal. Algunas leyes miran principalmente el propósito o la necesidad, no solo quién establece la cookie.
Ejemplo práctico
Entrás a un ecommerce y agregás un producto al carrito. El sitio puede asignar una cookie con un identificador de sesión. Cuando navegás a otra página, el navegador devuelve ese identificador y el servidor sabe qué carrito debe recuperar.
En el mismo sitio puede existir otra cookie que recuerde tu idioma y otra vinculada con analítica. Técnicamente todas son cookies, pero su propósito, duración, alcance y tratamiento de privacidad pueden ser completamente diferentes.
Ese es el punto clave: “cookie” describe el mecanismo; no describe por sí sola la finalidad.
Preguntas frecuentes
¿Qué es una cookie?
Una cookie HTTP es un pequeño fragmento de datos que un sitio web hace guardar en el navegador y que el navegador puede devolver automáticamente en solicitudes posteriores cuando coinciden las reglas de alcance de esa cookie. Permite mantener estado sobre HTTP —por ejemplo, una sesión, una preferencia o un identificador— y puede ser de sesión o persistente, y de primera o tercera parte según el contexto en el que se utiliza. No equivale a tracking ni a consentimiento: una cookie puede cumplir una función necesaria sin rastrear a una persona, y el tracking también puede realizarse mediante otras tecnologías; las obligaciones de información o consentimiento dependen del propósito, la tecnología y la normativa aplicable.
¿Para qué sirven las cookies?
Pueden mantener una sesión iniciada, recordar preferencias, conservar un carrito, asociar identificadores, medir uso o ayudar a personalizar y publicitar. El propósito depende de cada cookie; por eso cookie no es sinónimo de tracking.
¿Qué diferencia hay entre una cookie de sesión y una persistente?
Una cookie de sesión no define una fecha o duración persistente mediante Expires o Max-Age y normalmente se elimina cuando termina la sesión del navegador. Una persistente sí tiene una duración definida y puede permanecer entre sesiones hasta que vence o se elimina.
¿Qué diferencia hay entre first-party y third-party cookies?
La diferencia depende del contexto del sitio. Una first-party cookie está asociada al mismo site que la página que la persona visita; una third-party o cross-site cookie pertenece a un site diferente que participa en esa página o solicitud. No es simplemente una clasificación por quién es dueño de la empresa.
¿Cookie y tracking son lo mismo?
No. Una cookie es un mecanismo para guardar y devolver estado. Puede usarse para tracking, pero también para autenticación, seguridad, preferencias o carrito. A la inversa, el tracking puede usar otras tecnologías, como almacenamiento web, identificadores del dispositivo, píxeles o técnicas de fingerprinting.
¿Una cookie necesita consentimiento?
No existe una respuesta universal porque depende de la jurisdicción, del propósito y de cómo se use. Algunos marcos exigen consentimiento para cookies o tecnologías no esenciales y contemplan excepciones para usos estrictamente necesarios. Ser first-party o third-party, por sí solo, no determina la obligación.
¿Qué diferencia hay entre cookies y localStorage?
Ambos pueden conservar datos en el navegador, pero las cookies están integradas al protocolo HTTP y el navegador las envía automáticamente en solicitudes que coinciden con su alcance. localStorage permanece del lado del navegador hasta que el código de la aplicación lo lee y decide utilizarlo o enviarlo.
Referencias clave
IETF / RFC Editor. RFC 6265 — HTTP State Management Mechanism.
MDN Web Docs. Using HTTP cookies.
MDN Web Docs. Set-Cookie header.
MDN Web Docs. Third-party cookies.
Information Commissioner’s Office. Cookies and similar technologies.
IETF HTTP Working Group. Cookies: HTTP State Management Mechanism · trabajo de estandarización en curso.
Términos relacionados