logo
GeekFormat

Analizador de Set-Cookie

Analizador Set-Cookie

Pegue encabezados de respuesta Set-Cookie de varias líneas para inspeccionar atributos y marcar combinaciones riesgosas de SameSite / Secure.

Tarjetas de atributos de cookie

2 Set-Cookie
#1sessionabc123
path/
httponly(indicador)
secure(indicador)
samesiteLax
No se encontraron problemas obvios de atributos
#2preview1
max-age600 (10m 0s)

setCookieParser.attr.maxAgeHint

samesiteNone
secure(indicador)
setCookieParser.warn.missingHttpOnlysetCookieParser.warn.missingPath

Vista previa JSON

[
  {
    "index": 0,
    "raw": "session=abc123; Path=/; HttpOnly; Secure; SameSite=Lax",
    "name": "session",
    "value": "abc123",
    "decodedValue": "abc123",
    "attributes": [
      {
        "key": "path",
        "value": "/"
      },
      {
        "key": "httponly",
        "value": null
      },
      {
        "key": "secure",
        "value": null
      },
      {
        "key": "samesite",
        "value": "Lax"
      }
    ],
    "attributeMap": {
      "path": "/",
      "httponly": true,
      "secure": true,
      "samesite": "Lax"
    },
    "warnings": []
  },
  {
    "index": 1,
    "raw": "preview=1; Max-Age=600; SameSite=None; Secure",
    "name": "preview",
    "value": "1",
    "decodedValue": "1",
    "attributes": [
      {
        "key": "max-age",
        "value": "600"
      },
      {
        "key": "samesite",
        "value": "None"
      },
      {
        "key": "secure",
        "value": null
      }
    ],
    "attributeMap": {
      "max-age": "600",
      "samesite": "None",
      "secure": true
    },
    "warnings": [
      "warn.missingHttpOnly",
      "warn.missingPath"
    ]
  }
]

Pegue sus encabezados Set-Cookie y vea instantáneamente por qué el navegador no acepta sus cookies.

Relacionado

Casos de uso

  • Cuando los navegadores rechazan escribir cookies, identifique rápidamente si se trata de un problema de política SameSite, una bandera Secure faltante o una discrepancia Path/Domain
  • Depure cookies bloqueadas por navegadores en escenarios de inicio de sesión de terceros/SSO/iframe integrado — verifique que SameSite=None esté correctamente emparejado con Secure
  • Durante las auditorías de seguridad, verifique por lotes que todas las cookies devueltas por las API tengan HttpOnly establecido para evitar el robo XSS, y Secure para evitar la transmisión en texto plano HTTP
  • Al usar cookies con prefijo __Host-/__Secure-, verifique que se cumplan los requisitos obligatorios de RFC 6265bis para evitar el rechazo silencioso por parte de los navegadores
  • Al depurar el particionamiento de cookies de terceros CHIPS (Partitioned Cookie), confirme que Partitioned y Secure se declaren juntos
  • Al configurar Max-Age/Expires del lado del servidor, confirme valores válidos para evitar la expiración inmediata de cookies debido a desfase de reloj o Max-Age=0
  • Compare las diferencias de encabezado Set-Cookie entre entornos (desarrollo/staging/producción) para depurar el caso misterioso donde las cookies funcionan localmente pero desaparecen en producción
  • Copie encabezados de respuesta enteros directamente desde DevTools o respuestas curl — no es necesario eliminar manualmente el prefijo Set-Cookie:, la herramienta lo elimina automáticamente
  • Al redactar documentación de API o depurar errores de solicitudes WASM/WebWorker, pegue los resultados JSON analizados directamente en los documentos para ilustrar la estructura de las cookies

Características

  • Análisis independiente de múltiples cookies: Cada línea Set-Cookie se convierte en su propia tarjeta numerada que muestra nombre, valor y valor decodificado por URL — detecte las cookies problemáticas de un vistazo
  • Detección de atributos de seguridad en 14 puntos: Identifica automáticamente SameSite=None sin Secure, valores SameSite no válidos, Partitioned sin Secure, falta de HttpOnly, falta de Path, falta de SameSite, violaciones del prefijo __Host-, __Secure- sin Secure, Max-Age no válido/cero, punto inicial en Domain, Expires sin Max-Age y otros errores comunes
  • Desglose completo de atributos: SameSite, Secure, HttpOnly, Path, Domain, Expires, Max-Age, Partitioned enumerados punto por punto — los atributos de bandera y los atributos con valor se distinguen claramente
  • Conversión automática de Max-Age: Los segundos se convierten automáticamente a tiempo legible en días/horas/minutos/segundos, por ejemplo, Max-Age=2592000 se muestra como 30d
  • Visualización automática de valores decodificados por URL: Cuando los valores de cookie contienen codificación %XX, el texto original decodificado se muestra automáticamente (por ejemplo, sessionID%3Dabc → sessionID=abc) con un indicador de flecha verde
  • Validación de prefijos RFC 6265bis: Verifica estrictamente los requisitos de cumplimiento para cookies con prefijo __Host- y __Secure-, incluido Path=/, sin Domain y Secure obligatorio
  • Copia de encabezado bruto con un clic: Agrupe todas las líneas brutas de cookies analizadas para copiarlas fácilmente en correos electrónicos, issues o documentos para compartir con su equipo
  • Vista previa JSON estructurada: Los resultados del análisis admiten salida JSON con campos completos: name/value/decodedValue/attributes/attributeMap/warnings — utilizables directamente en scripts y casos de prueba
  • Procesamiento completamente local: El contenido de Set-Cookie se analiza completamente en su navegador, nunca se carga a ningún servidor, preservando la privacidad de sesiones sensibles, tokens y otros datos
  • Insignias de advertencia inteligentes: Cada problema se marca con una insignia de advertencia naranja que indica la razón exacta — no es necesario consultar los documentos RFC línea por línea
  • Entrada de varias líneas en masa: Pegue encabezados de respuesta enteros de una vez (por ejemplo, copiados del panel Network de Chrome DevTools) — el prefijo Set-Cookie: se elimina automáticamente para el análisis línea por línea
  • Admite valores entre comillas y con punto y coma: Procesa correctamente los valores de cookie entre comillas dobles y los puntos y coma en las fechas Expires según la especificación RFC, sin división incorrecta

Cómo Usar

  1. Abra el panel Network de las DevTools de su navegador, busque la solicitud de destino y copie el contenido de Set-Cookie desde la sección Response Headers (admite varias líneas — copie todas las cookies de una vez)
  2. Pegue los encabezados de respuesta Set-Cookie copiados en el área de entrada, una cookie por línea (no es necesario eliminar manualmente el prefijo Set-Cookie:; la herramienta lo elimina automáticamente)
  3. La herramienta analiza en tiempo real: la parte superior muestra cuántos encabezados Set-Cookie se detectaron, y cada cookie aparece a continuación como su propia tarjeta de atributos
  4. El encabezado de la tarjeta muestra el número, nombre de cookie y valor bruto; si el valor contiene codificación URL, el valor decodificado aparece después de una flecha verde
  5. El cuerpo de la tarjeta muestra los atributos punto por punto: SameSite, Secure, HttpOnly, Path, Domain, Max-Age, Expires, Partitioned, etc. Max-Age agrega automáticamente una mención entre paréntesis con la conversión a tiempo legible
  6. El pie de la tarjeta muestra los resultados de la inspección: insignias de advertencia naranjas señalan problemas específicos (cada problema tiene una explicación clara), las insignias verdes significan que no se detectaron problemas obvios
  7. Cuando necesite comparar con la configuración del servidor, haga clic en 'Copiar encabezados brutos' para copiar todas las líneas Set-Cookie originales; para procesamiento programático, consulte 'Vista previa JSON'

Preguntas Frecuentes

¿Por qué el encabezado Set-Cookie se estableció con éxito pero el navegador no guardó mi cookie?

Este es el problema más común. Los navegadores no informan activamente de errores; rechazan silenciosamente las cookies no conformes. Las causas comunes incluyen: SameSite=None sin Secure, cookies Secure establecidas en páginas HTTP (excepción localhost), prefijos __Host-/__Secure- que no cumplen las restricciones, discrepancia Domain/Path, superación del límite de tamaño de 4 KB, Max-Age siendo 0 o negativo. Recomendamos primero pegar sus encabezados Set-Cookie en esta herramienta para verificar las insignias de advertencia e identificar la causa específica, luego abrir Chrome DevTools → Application → Cookies, buscar un triángulo de advertencia amarillo bajo el dominio correspondiente y pasar el cursor para ver el motivo exacto del rechazo.

¿Cuál es exactamente la diferencia entre Strict, Lax y None de SameSite? ¿Cuándo usar cuál?

Strict no permite absolutamente el envío entre sitios — el más seguro, pero los usuarios que hacen clic desde enlaces externos parecen no haber iniciado sesión, adecuado para cookies de operaciones sensibles como pagos/cambios de contraseña. Lax es el valor predeterminado en Chrome 80+, permitiendo que se envíen cookies cuando los usuarios navegan de regreso a su sitio a través de GET de nivel superior desde enlaces externos (al hacer clic en un enlace externo a su sitio), pero no para subrecursos como iframe/img/script/XHR/formularios POST — valor recomendado para la mayoría de escenarios. None permite el envío en todos los escenarios entre sitios (para inicio de sesión único SSO, iframes integrados de terceros, llamadas API entre sitios) pero debe emparejarse con Secure, de lo contrario el navegador lo rechaza directamente.

¿Por qué SameSite=None debe emparejarse con Secure?

Esta es una regla que Chrome aplica desde la versión 80 (febrero de 2020), y Firefox, Edge y Safari han seguido el ejemplo. Como SameSite=None permite explícitamente el envío de cookies entre sitios, los atacantes pueden lanzar CSRF o escuchar más fácilmente en escenarios entre sitios, por lo que debe emparejarse con Secure (transmisión cifrada HTTPS) para mitigar riesgos. Si su cookie SameSite=None se establece sobre HTTP, el navegador la rechaza simplemente sin almacenarla. Esta herramienta detecta combinaciones SameSite=None-sin-Secure y las marca con advertencias rojas.

¿Debo usar Max-Age o Expires? ¿Cuál es la diferencia?

Prefiera Max-Age. Max-Age es tiempo relativo (expira después de N segundos), no depende del reloj del cliente y el navegador inicia la cuenta atrás al recibirlo; Expires es un punto en el tiempo absoluto, dependiendo de la hora local del ordenador del usuario (si un usuario pone su reloj en 1970, la cookie expira inmediatamente). Cuando ambos están presentes, Max-Age tiene prioridad (especificado explícitamente por RFC 6265). Si ninguno se establece, la cookie se convierte en una 'cookie de sesión' que expira cuando se cierra el navegador. Esta herramienta avisa cuando Expires está establecido sin Max-Age, recomendando agregar Max-Age. Nota: La unidad de Max-Age es segundos, no milisegundos.

¿Cuál es la diferencia entre Path=/ y no establecer Path?

Path determina para qué solicitudes de ruta URL el navegador incluirá esta cookie. Cuando Path no se establece, el navegador usa de forma predeterminada 'la ruta de la URL de respuesta sin el último segmento' — por ejemplo, al establecer una cookie desde /api/user/login, el Path predeterminado es /api/user/, por lo que las solicitudes bajo / y /order/ no incluirán esta cookie. Establecer explícitamente Path=/ hace que la cookie esté activa en todo el sitio. Tenga en cuenta que la coincidencia de Path es coincidencia de prefijo — Path=/api también coincide con /api/, /api/user, /api/v2/abc, etc. Las cookies con prefijo __Host- requieren Path=/.

¿Cuál es la diferencia entre un Domain con un punto inicial (como .example.com) y sin punto?

En navegadores modernos (versiones recientes de Chrome, Firefox, Edge, Safari), ambos son equivalentes — ambos hacen que la cookie sea válida para example.com y todos sus subdominios (a.example.com, b.c.example.com). El punto inicial era sintaxis antigua de la época de RFC 2109; RFC 6265 especifica explícitamente ignorar los puntos iniciales. Sin embargo, la forma sin punto se recomienda para legibilidad. Esta herramienta señala los Domain con punto inicial (no es un error, pero una notación heredada histórica). Nota: Cuando Domain no se establece, la cookie se aplica solo al host actual (los subdominios no la reciben); al establecer Domain se aplica también a subdominios.

¿Qué son los prefijos __Host- y __Secure-? ¿Puedo omitirlos?

Estos son prefijos de seguridad de nombre de cookie introducidos en RFC 6265bis para agregar restricciones estrictas a cookies de alta seguridad: cuando los navegadores ven que un nombre de cookie comienza con __Host-, imponen que Secure esté establecido, que Path sea / y que Domain no esté establecido — si no se cumple una condición, el almacenamiento se rechaza directamente; el prefijo __Secure- requiere que Secure esté establecido, los otros atributos son configurables. Las cookies también funcionan sin prefijos (la mayoría de las cookies no usan prefijos), pero __Host- se recomienda encarecidamente para cookies de alta seguridad como identificadores de sesión y tokens de autenticación, ya que previene ataques de inyección de cookies a nivel de subdominio/ruta. Esta herramienta detecta automáticamente el cumplimiento de ambos tipos de prefijo.

¿Las cookies HttpOnly son realmente seguras? ¿Previenen XSS y CSRF?

HttpOnly evita que JavaScript lea valores de cookie a través de document.cookie, lo que lo convierte en una línea de defensa importante para la <strong>mitigación del robo de sesión XSS</strong>, pero no es una solución milagrosa: los atacantes XSS aún pueden iniciar solicitudes en el navegador del usuario (que incluyen automáticamente cookies) para realizar acciones (este es el ámbito de CSRF); HttpOnly tampoco defiende contra ataques CSRF (requiere SameSite o tokens CSRF). El trío completo HttpOnly+Secure+SameSite=Lax/Strict debe usarse en conjunto para alcanzar un nivel de seguridad básico. Las cookies sensibles (session, JWT, access_token) deben ser HttpOnly; no las exponga al JS frontend a menos que sea necesario. Esta herramienta advierte sobre las cookies que carecen de HttpOnly.

¿Qué son las cookies Partitioned (CHIPS)? ¿Cuándo debo usarlas?

Partitioned es un nuevo atributo que Chrome introdujo en preparación para la eliminación de cookies de terceros, abreviatura de Cookies Having Independent Partitioned State (CHIPS). Las cookies de terceros tradicionales (como las establecidas por servicios de publicidad/integración en varios sitios) se comparten globalmente y podían usarse para el seguimiento de usuarios entre sitios. Con Partitioned agregado, los navegadores almacenan esta cookie de terceros por separado por sitio de nivel superior: la cookie de terceros que un usuario ve en el Sitio A es completamente independiente de la del Sitio B, sin compartir identidad entre sitios. Casos de uso: componentes de video/mapa/pago integrados, plugins de chat de terceros, iframes SSO entre sitios integrados. Partitioned debe usarse con Secure y se recomienda con el prefijo __Host-.

¿Cuántos datos puede almacenar una sola cookie? ¿Cuántas se pueden colocar por dominio?

Según RFC 6265, los navegadores deben admitir al menos 4096 bytes por cookie (nombre, valor y atributos incluidos). Los navegadores principales (Chrome/Firefox/Safari/Edge) aplican todos este límite; el excedente se silenciosamente truncado o eliminado. Los límites de número varían según el navegador: Chrome permite ~180 por dominio, Firefox ~150, Safari ~600 (y se ve afectado por la política de limpieza de 7 días de ITP), después de lo cual los navegadores expulsan las cookies más antiguas mediante una estrategia LRU. Recomendamos que las cookies solo almacenen identificadores de sesión — no coloque grandes bloques de datos de negocio en cookies (almacene los datos de negocio en localStorage o sesiones del lado del servidor).

¿Admite la herramienta el análisis de Set-Cookie copiado directamente desde Chrome DevTools? ¿Debo eliminar los prefijos manualmente?

Totalmente compatible — no se requiere procesamiento manual. Puede ir a Chrome DevTools → panel Network, hacer clic en la solicitud de destino, hacer clic derecho en el valor Set-Cookie en la sección Response Headers y copiar directamente (para varias líneas, Ctrl/⌘+clic para selección múltiple o copiar el bloque completo), luego pegar en el área de entrada de esta herramienta. La herramienta elimina automáticamente el prefijo Set-Cookie: del principio de cada línea (insensible a mayúsculas/minúsculas), procesa espacios en blanco al principio/final de línea, procesa correctamente caracteres especiales como comas y puntos y coma en fechas Expires y procesa correctamente valores de cookie entre comillas dobles.

¿Por qué los caracteres chinos o especiales en los valores de cookie se convierten a forma %XX?

RFC 6265 exige que los valores de cookie utilicen solo un subconjunto seguro del juego de caracteres ASCII y no puedan contener directamente caracteres chinos, espacios, comas, punto y coma, etc. Muchos frameworks del lado del servidor codifican automáticamente en URL (encodeURIComponent/codificación porcentual) los caracteres no ASCII al establecer cookies, por ejemplo, '你好' se codifica como %E4%BD%A0%E5%A5%BD. Los navegadores también mantienen la forma codificada al devolverlas. Cuando esta herramienta detecta que los valores contienen codificación %XX, muestra automáticamente el texto original decodificado por decodeURIComponent junto al valor bruto con una flecha verde para facilitar la verificación del contenido real.

¿Cuál es la diferencia entre Set-Cookie y el encabezado de solicitud Cookie?

Son encabezados en direcciones completamente opuestas: Set-Cookie es un encabezado de respuesta (servidor → navegador), aparece solo en respuestas, puede aparecer varias veces y establece cada vez una cookie con atributos completos (Secure/HttpOnly/Path/Domain/etc.); Cookie es un encabezado de solicitud (navegador → servidor), aparece solo una vez por solicitud y contiene pares name=value planos (name1=v1; name2=v2) de todas las cookies que coinciden con el ámbito, sin ninguna información de atributo. Esto significa que los servidores no pueden saber a partir de las solicitudes si una cookie tiene HttpOnly o Secure establecido — la información de atributo solo es retenida por el navegador al almacenarla localmente. Para analizar encabezados de solicitud Cookie, utilice el <a href='/network/http-cookie-parser/'>Analizador de encabezado de solicitud Cookie</a> asociado.

¿Por qué mis cookies desaparecen después de unos días en Safari?

Este es el mecanismo de Prevención de Seguimiento Inteligente (ITP: Intelligent Tracking Prevention) de Safari en funcionamiento. Desde ITP 2.1, si un usuario no interactúa directamente con un dominio durante 7 días (es decir, no ha visitado directamente el sitio de ese dominio), Safari limpia todas las cookies y datos de sitio bajo ese dominio, independientemente de cuánto tiempo se establezca Max-Age/Expires. Esto tiene el mayor impacto en servicios integrados de terceros, mientras que las cookies del sitio principal no se ven afectadas siempre que los usuarios sigan visitando. Además, las restricciones de Safari sobre cookies de terceros son más estrictas que las de Chrome. Las soluciones incluyen: usar el atributo Partitioned, solicitar permisos a través de la API Storage Access o actualizar las cookies cuando los usuarios visitan el sitio principal. La sección de resolución de problemas de esta herramienta contiene orientación de depuración de Safari más detallada.

¿Admite la herramienta el análisis en masa de varios encabezados Set-Cookie? ¿El contenido de las cookies se carga en servidores?

El análisis en masa es compatible. El área de entrada admite pegar cualquier número de encabezados Set-Cookie de varias líneas (por ejemplo, pegar un bloque de encabezado de respuesta entero de una vez). Cada Set-Cookie se analiza con numeración independiente, con varias tarjetas de atributos que muestran sus respectivos atributos y advertencias. Todos los procesos de análisis se ejecutan completamente localmente en su navegador (procesamiento JavaScript frontend puro). El contenido de las cookies nunca se carga a ningún servidor, no se realizan solicitudes de red, y la información sensible como sesiones/tokens que pegue nunca abandona su ordenador — utilícelo con confianza.

术语表

Set-Cookie
Encabezado de respuesta HTTP a través del cual el servidor indica al navegador que almacene cookies; puede aparecer varias veces en una sola respuesta.
Cookie (encabezado de solicitud)
Encabezado de solicitud HTTP que contiene una lista de pares nombre-valor de cookies que cumplen con el ámbito, adjuntados automáticamente por el navegador, sin atributos.
HttpOnly
Bandera de atributo de cookie. Cuando se establece, JavaScript no puede leer la cookie a través de document.cookie, sirviendo principalmente para defenderse del robo de sesión XSS.
Secure
Bandera de atributo de cookie. Cuando se establece, el navegador solo envía esta cookie sobre conexiones cifradas HTTPS (o localhost).
SameSite
Atributo de cookie que controla si las cookies se envían en solicitudes de sitios cruzados; los valores son Strict/Lax/None. El valor predeterminado es Lax en Chrome 80+.
Max-Age
Atributo de cookie que especifica la duración de la cookie en segundos. Tiene prioridad sobre Expires, recomendado. =0 significa eliminación inmediata.
Expires
Atributo de cookie que especifica un punto en el tiempo de expiración específico (HTTP-date), dependiendo del reloj del cliente.
Path
Atributo de cookie que limita el prefijo de ruta URL donde la cookie está activa; por defecto la parte de directorio de la URL de respuesta.
Domain
Atributo de cookie que limita el dominio donde la cookie está activa. Si no se establece, solo el host actual; si se establece, también se aplica a subdominios.
Partitioned (CHIPS)
Bandera de atributo de cookie que activa el almacenamiento particionado de cookies de terceros; el enfoque de reemplazo después de que Chrome elimine las cookies de terceros, debe emparejarse con Secure.
Prefijo __Host-
Restricción de seguridad de prefijo de nombre de cookie. Requiere Secure, Path=/, sin atributo Domain; los navegadores rechazan el almacenamiento en caso de violación.
Prefijo __Secure-
Restricción de seguridad de prefijo de nombre de cookie. Requiere que se establezca Secure; los navegadores rechazan el almacenamiento en caso de violación.
Cookie de sesión (Session Cookie)
Una cookie sin Max-Age ni Expires establecidos; se elimina automáticamente cuando se cierra el navegador.
Cookie de terceros (Third-party Cookie)
Una cookie establecida bajo un dominio distinto de la página visitada actualmente, típicamente por publicidad, análisis, iframes integrados y otros servicios de terceros; está siendo gradualmente restringida en todos los navegadores.

Tabla de comparación rápida de las tres estrategias de SameSite

Tabla de referencia completa de atributos Set-Cookie (RFC 6265bis)

Límites comunes de tamaño y número de Set-Cookie por navegador

Troubleshooting