Analiza headers Set-Cookie y Cookie con detección de atributos y seguridad
Pega un header Set-Cookie o Cookie para analizar sus atributos
También podrías necesitar
Las cookies HTTP son el mecanismo principal para mantener estado entre peticiones HTTP, que por diseño es sin estado (stateless). Se usan para sesiones de usuario, preferencias, autenticación, tracking de analytics y personalización. Cada cookie tiene una serie de atributos que controlan su comportamiento y seguridad: Domain (a qué dominio se envía), Path (a qué rutas), Expires/Max-Age (cuándo caduca), Secure (solo se envía por HTTPS), HttpOnly (inaccesible desde JavaScript, protege contra XSS), y SameSite (Strict/Lax/None, controla cuándo la cookie se envía en cross-site requests, protege contra CSRF). Un mal manejo de cookies es una de las fuentes más comunes de vulnerabilidades web. Esta herramienta parsea headers Set-Cookie y Cookie (ambos formatos) y presenta cada atributo en una tarjeta visual con badges de estado. Detecta la combinación insegura SameSite=None + Secure=false (que los navegadores modernos rechazan) y muestra advertencias claras.
¿Cuál es la diferencia entre header Set-Cookie y Cookie?
Set-Cookie es el header de respuesta que el servidor envía para pedir al navegador que guarde una cookie: 'Set-Cookie: session=abc; Path=/; HttpOnly'. Contiene el nombre, valor y todos los atributos. Cookie es el header de petición que el navegador envía en cada request posterior con las cookies aplicables al dominio y ruta: 'Cookie: session=abc; theme=dark; lang=es'. Contiene solo nombre=valor (sin atributos). Esta herramienta detecta y parsea ambos formatos automáticamente.
¿Qué significa SameSite=Strict vs Lax vs None?
SameSite controla cuándo el navegador envía la cookie en requests cross-site. Strict: nunca se envía en cross-site (máxima protección, pero rompe login persistente si vienes desde otro sitio). Lax (default en navegadores modernos): se envía en navegación top-level GET, no en POSTs cross-site (protección razonable contra CSRF). None: se envía en cualquier request, incluye cross-site (necesario para cookies de terceros, ej. iframes embebidos), pero requiere Secure obligatoriamente.
¿Cuándo debo usar HttpOnly?
Siempre que la cookie contenga información sensible como tokens de sesión, JWTs o identificadores de autenticación. HttpOnly hace que la cookie sea inaccesible desde JavaScript (document.cookie no la muestra), lo cual es una defensa crítica contra XSS: incluso si un atacante inyecta un script malicioso, no podrá leer la cookie de sesión para hacer session hijacking. Las cookies de preferencias UI (como tema, idioma) no requieren HttpOnly porque JavaScript necesita leerlas.
¿Qué diferencia hay entre Expires y Max-Age?
Expires define un momento absoluto en formato HTTP date: 'Wed, 31 Dec 2025 23:59:59 GMT'. Depende de que el reloj del cliente esté correcto y respete el offset UTC. Max-Age define una duración relativa desde el momento en que el cliente recibe la cookie, en segundos: 'Max-Age=2592000' = 30 días. Max-Age tiene prioridad sobre Expires si ambos están presentes. RFC 6265 recomienda usar Max-Age por su fiabilidad, aunque muchos servidores siguen enviando Expires por compatibilidad con parsers antiguos.
¿Qué es una session cookie?
Una session cookie es una cookie sin atributos Expires ni Max-Age. El navegador la elimina cuando cierras la sesión del navegador (cierras todas las ventanas, o cierras el navegador). Son útiles para cookies de sesión de login que no queremos persistir en el disco del usuario. Ojo: los navegadores modernos con 'restaurar sesión al abrir' pueden persistir cookies de sesión entre reinicios del navegador — no dependas de que se borren en todos los casos.