Validador de prefijos de cookies HTTP｜Reglas __Host- y __Secure- línea a línea

Pega tus cabeceras Set-Cookie y la herramienta comprueba cada línea frente a las reglas de RFC 6265bis para los prefijos __Host- y __Secure-. Cada línea recibe una etiqueta PASS / FAIL, y las líneas con error indican qué requisito se incumplió junto a una tabla con los atributos analizados: Path, Domain, Secure, HttpOnly, SameSite. Sin servidor: solo pegar y leer.

💡 Sobre esta herramienta

__Host- y __Secure- son prefijos de cookie: prefijos especiales en el nombre que hacen que el navegador exija ciertos atributos. Si el nombre de una cookie empieza por uno de ellos y no se cumplen los requisitos, el navegador ignora en silencio toda la cabecera Set-Cookie. Ese descarte silencioso es justo lo que convierte un "puse __Host-session pero el usuario nunca inicia sesión" en una tarde entera de depuración.

Los dos prefijos piden cosas distintas. __Secure- solo exige el atributo Secure. __Host- es más estricto: además de Secure, requiere Path=/ (exactamente la raíz) y ningún atributo Domain. Quitar Domain fija la cookie al host exacto que la emitió, lo que bloquea el cookie tossing entre subdominios: un atacante en evil.example.com no puede escribir una cookie que llegue a app.example.com. En cuanto pones un CDN o un balanceador delante de una arquitectura multi-host, esa distinción es la que más se pasa por alto.

Para entender el porqué, conviene separar dos conceptos que se confunden a menudo. Secure controla cómo viaja la cookie (solo por HTTPS); Domain controla a quién se envía. El prefijo __Host- combina ambos en una garantía única: transporte cifrado y destino fijado a un único host. La herramienta recibe un lote completo de líneas Set-Cookie, detecta el prefijo de cada una y aplica solo las reglas que ese prefijo activa, mostrando motivos como "__Host- no debe incluir el atributo Domain".

🧐 Preguntas frecuentes

¿Qué diferencia hay entre __Host- y __Secure-? La exigencia. __Secure- solo necesita el atributo Secure. __Host- necesita Secure más Path=/ exacto y sin atributo Domain. __Host- ofrece la mayor garantía de vinculación a un host.

¿Distinguen mayúsculas y minúsculas los prefijos? No. El navegador trata __Host- y __host- (minúsculas) como el mismo prefijo y aplica las mismas reglas. RFC 6265bis pasó a comparar sin distinguir mayúsculas para cerrar una evasión: un servidor que compara los nombres de cookie sin distinguir mayúsculas podría ser engañado con una variante en minúsculas enviada sin Secure. La herramienta también aplica las reglas sin distinguir mayúsculas.

¿Por qué falla una cookie __Host- con Path=/api? __Host- requiere Path=/, exactamente la raíz. Una subruta como /api incumple el requisito y el navegador descarta la cookie. Si necesitas acotar la ruta, usa __Secure-.

¿Cómo se tratan las líneas sin prefijo? Una línea sin prefijo privilegiado no tiene ningún requisito que comprobar, así que se marca como PASS y se etiqueta "(sin prefijo)". La tabla de atributos se muestra igualmente para revisar qué se configuró.

¿Sale de mi equipo algo de lo que pego? No. Cada línea se analiza en tu navegador y las cabeceras Set-Cookie que pegas nunca se envían a un servidor, así que pegar nombres y valores reales de producción no sale de tu equipo.

📚 Por qué la regla vive en el nombre y no en un atributo

Lo ingenioso de __Host- y __Secure- es que el requisito va incrustado en el nombre en lugar de viajar como atributo. Una cabecera Set-Cookie va del servidor al navegador con todos sus atributos, pero cuando el navegador devuelve después la cookie (la cabecera de petición Cookie) solo viajan el nombre y el valor: Secure, Path y compañía desaparecen. Por eso el servidor no puede inspeccionar una cookie entrante y confirmar que se guardó con Secure. El prefijo cierra ese hueco: codifica el requisito en el nombre, y la simple llegada de una cookie llamada __Host-session es la prueba de que el navegador exigió Secure y vinculación a host al guardarla, porque la especificación obliga al navegador a descartar en silencio toda Set-Cookie que no cumpla. Garantizar la seguridad mediante una convención de nombres en vez de un atributo nuevo es también la razón por la que los prefijos se desplegaron de forma retrocompatible: aprovechan el formato de cookie existente sin cambiar ni un byte de su gramática.