¿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.