🍪 Inspector de Cookies
Introduce una URL para obtener cada cabecera Set-Cookie y analizar Secure / HttpOnly / SameSite / Domain / Path / Expires, prefijos y límites de tamaño.
📚 Referencia de Atributos
• Secure: Solo por HTTPS
• HttpOnly: Inaccesible a JavaScript (protección XSS)
• SameSite=Strict: No enviado en peticiones cross-site
• SameSite=Lax: Solo en navegación GET de nivel superior (predeterminado)
• SameSite=None: Enviado cross-site (requiere Secure)
• __Secure- prefix: Requiere flag Secure
• __Host- prefix: Requiere Secure + sin Domain + Path=/
• Partitioned (CHIPS): En contexto de tercero particionado
📖 Qué te dice este diagnóstico
Este diagnóstico se conecta a la URL indicada, analiza las cabeceras Set-Cookie devueltas e informa de si llevan Secure, HttpOnly, SameSite y demás. Las cookies que JavaScript escribe después mediante document.cookie no se ven aquí. Las etiquetas de analítica y publicidad casi siempre usan esa vía, así que el número realmente almacenado en el navegador suele ser mayor que el listado: mira la pestaña Application de las devtools para el cuadro completo.
| Elemento | Qué significa | Cómo corregirlo |
|---|---|---|
| SameSite sin especificar | Si falta, los navegadores modernos la tratan como Lax. Una cookie Lax se envía sólo en navegación GET de nivel superior: nunca en un POST entre sitios, dentro de un iframe ni en fetch. El fallo por el que la sesión desaparece justo cuando la pasarela de pago devuelve al usuario por POST es casi siempre este. |
Decláralo siempre de forma explícita según el caso: SameSite=Lax para una sesión normal, Strict para un panel de administración donde importa resistir el CSRF, y SameSite=None; Secure para flujos de pago que vuelven por POST o para uso embebido. None sin Secure hace que la cookie se descarte por completo, así que escríbelos juntos. |
| Se ha puesto el atributo Domain | Contra lo que sugiere la intuición, Domain=example.com amplía el alcance en lugar de reducirlo. Si lo omites, la cookie sólo va a ese host exacto; si lo pones, va a todos los subdominios. Basta con que un host como user.example.com permita publicar contenido a los usuarios para que la cookie de sesión principal sea legible desde allí. |
Lo más seguro por defecto es no poner Domain y usarlo sólo donde compartir sea realmente necesario, con el alcance más estrecho. Para endurecerlo aún más, nombra la cookie con el prefijo __Host-: el navegador impone entonces Secure, sin Domain y Path=/, de modo que un descuido de configuración no puede ampliarla. |
| Demasiadas cookies o demasiado grandes | Una cookie guarda unos 4 KB y un dominio unas 50, pasado lo cual el navegador expulsa en silencio las más antiguas. Es una explicación sorprendentemente frecuente de quejas difíciles de reproducir, como cierres de sesión esporádicos o un carrito que a veces se vacía. Además, las cookies viajan en cada petición al dominio, así que consumen ancho de banda incluso al pedir imágenes y CSS. | Guarda sólo un identificador en la cookie y el estado en el servidor. Meter un JWT entero supera los 4 KB con facilidad. Lleva las preferencias que no son de autenticación —el tema visual, un banner cerrado— a localStorage para que dejen de viajar en cada petición, y sirve los recursos estáticos desde otro dominio o un CDN donde no se aplique ninguna cookie. |
Lo que exige la directiva ePrivacy de la UE y las normas nacionales equivalentes es que no se escriba ninguna cookie antes del consentimiento, no que se muestre un banner. Un montaje en el que las etiquetas de analítica emiten Set-Cookie antes de que nadie pulse aceptar puede incumplir el requisito aunque haya banner. Mirar las cookies devueltas justo al abrir tu portada con este diagnóstico da una primera lectura. Técnica y legalmente, la medida más segura es tener menos cookies.