Formato nuevo
Cookies del navegador: para qué sirven, cómo funcionan y seguridad
Una cookie es un dato pequeño que el sitio guarda en el navegador para reconocerte en peticiones posteriores: sesión de login, idioma, carrito, IDs de analytics. No es un virus, pero tampoco polvo inocuo — con cookies se construyen perfiles y se mantiene la sesión iniciada.
Abajo: propósito, tipos, escenarios de tracking, seguridad y qué debe planear el dueño del sitio (consentimiento, HTTPS, caducidad). Importante: las cookies casi nunca guardan la contraseña en texto claro — solo tokens o IDs.
Para qué sirven las cookies
El servidor (o un script) envía el header `Set-Cookie`; el navegador guarda un par nombre=valor y lo reenvía en peticiones posteriores a ese dominio. Así el sitio reconoce la sesión sin pedir login en cada página.
Tareas típicas: auth, carrito, idioma/moneda, «ya viste el banner», IDs de analytics (con consentimiento cuando toque).
En corto:
- datos en el navegador, no un programa
- ligadas a dominio y path
- tienen caducidad y flags de seguridad
- no sustituyen del todo la sesión en servidor
Cookies de tracking y marketing
Redes de ads y widgets ponen IDs para unir visitas entre sitios (mientras vivan las third-party) o con otras técnicas. Para el usuario es personalización y retargeting; para el negocio — atribución, pero también deber de transparencia.
La analytics first-party en tu propio dominio suele ser más predecible en la era de límites a terceros.
Para el dueño del sitio:
- inventario de cada tag
- política de cookies en lenguaje claro
- no cargar marketing antes del consentimiento si el régimen lo exige
- minimizar scripts de terceros
Seguridad y flags
HttpOnly — JS no puede leer la cookie (protege del robo de sesión vía XSS). Secure — solo HTTPS. SameSite — limita el envío desde otros sitios (CSRF). Una sesión corta reduce el daño si hay fuga.
Para usuarios: no quedarte logueado en PCs compartidos, actualiza el navegador, cuidado con las extensiones, no metas contraseñas en páginas HTTP.
Riesgos:
- XSS → cookie de sesión robada
- MITM en HTTP sin Secure
- phishing más reutilizar la sesión
- terceros de más con acceso amplio
Privacidad y ley
Las cookies pueden relacionarse con datos personales si identifican al usuario. Hace falta política, base de tratamiento e interfaz de control donde la ley y el sentido común lo pidan.
No copies un banner «Accept all» ajeno sin bloquear de verdad los tags opcionales — solo molesta y no quita el riesgo.
Mínimo del sitio:
- página de política de cookies/privacidad
- separación necesarias vs opcionales
- forma de retirar el consentimiento
- registro de qué tags se ponen de verdad
Práctica para el webmaster
Documenta la lista de cookies (nombre, propósito, caducidad, quién las pone). Cookies de sesión — HttpOnly + Secure + SameSite según haga falta. No hinches la vida a «10 años» sin motivo.
Tras lanzar un CMP/banner, verifica que analytics y ads esperan de verdad al consentimiento. Revisa Metrika/GA por pérdida de datos.
Checklist de release:
- tabla de cookies en la política
- flags en cookies de auth
- test de login/carrito
- test «rechazar opcionales»
- monitor de errores de tags
FAQ
¿Las cookies guardan mi contraseña?
En sitios bien hechos — no. Guardan un ID de sesión o un token. Si un servicio mete la contraseña en una cookie, es mala práctica y un riesgo.
¿Cuál es la diferencia entre session y persistent?
Las de sesión viven hasta cerrar el navegador (a grosso modo). Las persistentes hasta Expires / Max-Age.
¿Qué es una cookie de terceros?
La pone un dominio distinto al del sitio que abriste (a menudo ads o widgets). Los navegadores las van cerrando cada vez más.
¿Para qué necesita cookies un sitio?
Login, carrito, tests A/B, analytics, personalización, antifraude. Sin ellas muchos servicios «olvidan» al usuario.
¿Son peligrosas las cookies?
Riesgos: robo de sesión (XSS), manipulación (sin Secure/HttpOnly) y tracking. Se mitigan con higiene técnica y hábitos del usuario.
¿Hace falta un banner de consentimiento?
Depende de la jurisdicción y de qué tags pongas. En Rusia — ley de datos personales y tu política; en la UE — GDPR/ePrivacy. Abogado más cookies estrictamente necesarias.
¿Cómo veo las cookies?
DevTools → Application/Storage → Cookies. O ajustes del navegador: lista de sitios y borrar.
¿Bloquear cookies rompe el sitio?
A menudo sí para carrito y cuenta. En una web de brochure — menos. Ofrece un fallback y un mensaje honesto.
¿El banner dice Accept all — y los tags opcionales disparan antes de elegir?
Inventariamos cookies, ponemos flags Secure/HttpOnly y hacemos que los scripts opcionales esperen al consentimiento.
Hablar del proyecto
