Analizador de Encabezados de Cookies

El Analizador de Headers de Cookies decodifica los headers Cookie enviados por el navegador y los headers Set-Cookie enviados por el servidor en formatos estructurados y legibles, extrayendo nombres de cookies, valores y atributos de seguridad como HttpOnly, Secure, SameSite, expiración, alcance de dominio y ruta. Pega un header como session_id=abc123; Path=/; HttpOnly; Secure; SameSite=Strict y obtén un desglose claro de cada atributo con explicaciones de lo que hace cada uno.

Entendiendo las cookies HTTP

Las cookies son el mecanismo principal de la web para mantener el estado entre peticiones. HTTP en sí es sin estado -- cada petición es independiente, y el servidor no tiene una forma integrada de recordar que dos peticiones vinieron del mismo usuario. Las cookies resuelven esto permitiendo al servidor almacenar un pequeño dato en el navegador, que el navegador luego envía de vuelta con cada petición subsiguiente. Así es como funcionan las sesiones de inicio de sesión, cómo los carritos de compras persisten entre cargas de página, y cómo los sitios recuerdan tus preferencias de idioma.

El ciclo de vida de la cookie comienza cuando un servidor incluye un header Set-Cookie en una respuesta HTTP. Este header contiene el nombre y valor de la cookie, más atributos opcionales que controlan su tiempo de vida, alcance y propiedades de seguridad. El navegador almacena la cookie y la incluye en el header Cookie de peticiones futuras a ese dominio. Un solo header Set-Cookie establece una cookie, pero un solo header Cookie puede llevar muchas cookies, separadas por puntos y coma.

Lo que hace a las cookies difíciles de manejar es la cantidad de atributos que afectan su comportamiento. Los atributos Domain y Path controlan qué URLs reciben la cookie. La bandera Secure restringe la transmisión a HTTPS. La bandera HttpOnly impide que JavaScript lea la cookie, protegiendo contra ataques de cross-site scripting (XSS). El atributo SameSite controla si la cookie se envía con peticiones cross-origin, que es la defensa principal contra cross-site request forgery (CSRF). Configurar estos atributos correctamente es crítico tanto para la funcionalidad como para la seguridad, y este analizador te ayuda a verificarlos mostrando cada atributo con una explicación en lenguaje simple de lo que hace.

Cómo analizar un header de cookie

1. Pega el valor de un header Cookie o Set-Cookie en el campo de entrada.
2. Selecciona el tipo de header (Cookie para headers de petición, Set-Cookie para headers de respuesta).
3. Haz clic en Analizar para extraer todas las cookies y sus atributos en una vista estructurada.
4. Revisa los valores decodificados, las explicaciones de atributos y cualquier recomendación de seguridad.

Ejemplos de análisis de headers de cookies

Analizando un header Cookie del navegador

Entrada (header Cookie):

session_id=abc123def456; theme=dark; lang=en-US; _ga=GA1.2.123456789.1609459200

Salida analizada:

Analizando un header Set-Cookie de respuesta

Entrada (header Set-Cookie):

session_id=abc123def456; Path=/; Domain=.example.com; Expires=Thu, 01 Jan 2026 00:00:00 GMT; HttpOnly; Secure; SameSite=Strict

Salida analizada:

Cuándo usar el analizador de headers de cookies

• Depuración de problemas de autenticación -- Inspecciona las cookies de sesión para verificar que se están configurando correctamente con los valores adecuados de dominio, ruta y expiración.
• Auditoría de seguridad de cookies -- Verifica que las cookies de sesión tengan las banderas HttpOnly, Secure y SameSite configuradas para prevenir ataques XSS y CSRF.
• Análisis de cookies de terceros -- Identifica cookies de rastreo de widgets de analítica, publicidad y redes sociales y entiende su alcance.
• Solución de problemas de cookies cross-domain -- Verifica la configuración de Domain y SameSite cuando las cookies no se envían en peticiones cross-origin.
• Revisión de cumplimiento -- Inventaría todas las cookies que un sitio establece, sus propósitos y sus tiempos de vida para documentación GDPR o CCPA.
• Respuesta a incidentes -- Durante un incidente de seguridad, analiza rápidamente todas las cookies para identificar tokens de sesión, su alcance y si están correctamente protegidas.

Cómo funcionan los headers de cookies

Cookie vs. Set-Cookie

Estos dos headers sirven direcciones opuestas del flujo de cookies HTTP:

• Set-Cookie es enviado por el servidor en una respuesta para crear o actualizar una cookie en el navegador. Cada header Set-Cookie establece una cookie con sus atributos.
• Cookie es enviado por el navegador en una petición, conteniendo todas las cookies que coinciden con el dominio y ruta de la URL actual. Múltiples cookies se separan por punto y coma.

Referencia de atributos de cookies

Valores del atributo SameSite

• Strict -- La cookie nunca se envía en peticiones cross-site. Lo mejor para cookies de sesión sensibles.
• Lax -- La cookie se envía en navegación de nivel superior (hacer clic en un enlace) pero no en subpeticiones cross-site (imágenes, iframes, AJAX). Este es el valor por defecto del navegador.
• None -- La cookie se envía en todas las peticiones cross-site. Requiere la bandera Secure.

Límites de tamaño y cantidad de cookies

Los navegadores imponen límites a las cookies que debes conocer:

Cuando se exceden estos límites, los navegadores eliminan silenciosamente las cookies más antiguas. Si tu aplicación pierde repentinamente el estado de sesión, exceder los límites de cookies es una causa común pero frecuentemente ignorada.

Consejos prácticos de seguridad para cookies

La regla más importante para las cookies de sesión es siempre configurar las tres banderas de seguridad: HttpOnly, Secure y SameSite. La bandera HttpOnly impide que JavaScript acceda a la cookie vía document.cookie, lo que significa que una vulnerabilidad XSS no puede robar tu token de sesión. La bandera Secure asegura que la cookie nunca se envíe por HTTP sin cifrar, incluso si un usuario visita accidentalmente la versión HTTP de tu sitio. Y SameSite=Strict (o como mínimo Lax) impide que la cookie se envíe en peticiones cross-site, que es la defensa principal contra ataques CSRF. Omitir cualquiera de estas banderas deja un hueco en tu postura de seguridad.

El alcance del dominio de cookies es otra área donde los errores son comunes. Si configuras Domain=.example.com (con el punto inicial), la cookie se envía a example.com y cada subdominio -- incluyendo evil.example.com si un atacante puede registrar un subdominio. Para cookies de sesión, es más seguro omitir el atributo Domain completamente, lo que restringe la cookie al origen exacto que la estableció. Solo usa el alcance de dominio cuando genuinamente necesites compartir cookies entre subdominios, como para single sign-on entre app.example.com y api.example.com.

Ten cuidado con la interacción entre SameSite=None y la bandera Secure. Los navegadores modernos requieren Secure cuando se establece SameSite=None -- si omites Secure, la cookie se rechaza silenciosamente. Este requisito existe porque SameSite=None le dice al navegador que envíe la cookie en peticiones cross-site, y hacerlo por HTTP sin cifrar expondría la cookie a interceptores de red. Si tu cookie de terceros se está eliminando silenciosamente, verifica que ambos atributos estén presentes.

Preguntas frecuentes

¿Por qué mi header Set-Cookie no tiene efecto?

Las causas comunes incluyen: falta de la bandera Secure cuando se usa SameSite=None, establecer Domain a un dominio diferente al origen de la respuesta, el navegador bloqueando cookies de terceros, o Path configurado a una ruta que no coincide con la página actual.

¿Cuál es la diferencia entre Expires y Max-Age?

Expires usa una fecha absoluta (Thu, 01 Jan 2026 00:00:00 GMT), mientras que Max-Age especifica segundos desde ahora (3600 = 1 hora). Cuando ambos están presentes, Max-Age tiene precedencia. Si ninguno está configurado, la cookie es una cookie de sesión y se elimina cuando el navegador se cierra.

¿Cómo puedo saber si una cookie es de rastreo?

Los indicadores comunes incluyen: nombres que comienzan con _ga, _gid (Google Analytics), _fbp, _fbc (Facebook), o _uet (Bing). Las cookies con Domain configurado a un dominio de terceros y valores largos de Max-Age (frecuentemente 1-2 años) son típicamente cookies de rastreo.

¿Por qué mis cookies no se envían en peticiones API cross-origin?

Las peticiones cross-origin requieren configuración específica tanto en el cliente como en el servidor. El cliente debe establecer credentials: 'include' en las opciones de fetch, y el servidor debe responder con Access-Control-Allow-Credentials: true y un origen específico (no *) en Access-Control-Allow-Origin. La cookie también necesita SameSite=None; Secure para enviarse cross-origin.

¿Qué pasa cuando se alcanza el límite de cookies del navegador?

Los navegadores eliminan silenciosamente las cookies más antiguas o menos usadas recientemente para hacer espacio para las nuevas. No hay error ni advertencia. Si tu aplicación depende de muchas cookies, considera consolidarlas en una sola cookie codificada en JSON o mover el estado a sesiones del lado del servidor.

¿Cómo funcionan los prefijos de cookies como __Secure- y __Host-?

Estos son prefijos de nombre de cookie que imponen requisitos de seguridad adicionales. Una cookie llamada __Secure-session debe tener la bandera Secure. Una cookie llamada __Host-session debe tener tanto Secure como Path=/, y no debe tener un atributo Domain. Estos prefijos proporcionan defensa en profundidad contra ataques de manipulación de cookies.

Herramientas relacionadas

• HTTP Header Formatter - Analiza y formatea headers HTTP incluyendo Set-Cookie
• CORS Header Explainer - Entiende los headers CORS que afectan la transmisión de cookies en peticiones cross-origin
• HTTP Status Code Lookup - Busca códigos de estado para respuestas que establecen cookies
• User-Agent Parser - Analiza cadenas User-Agent para entender qué navegador envió las cookies
• curl Command Builder - Construye comandos curl con headers de cookies para pruebas