Atributos de cookies: Secure, HttpOnly, SameSite, Domain, Path y el prefijo __Host-

Qué es

Una cabecera Set-Cookie lleva un nombre, un valor y atributos. RFC 6265 y su borrador sucesor (rfc6265bis, que añade SameSite y los prefijos) los definen:

• Domain: si se omite, la cookie solo se devuelve al host de origen (exclusiva del host). Fijado a example.com, se envía a ese host y a todos sus subdominios. Un valor que no cubra el origen se rechaza, y RFC 6265 señala que muchos agentes de usuario también rechazan sufijos públicos como co.uk.
• Path: por defecto es el directorio de la ruta de la solicitud; la coincidencia se basa en prefijos. RFC 6265 dice que «no se puede confiar en él por motivos de seguridad».
• Secure: se envía solo por canales seguros. RFC 6265 advierte que protege la confidencialidad, no la integridad; el borrador añade que los orígenes no seguros no pueden sobrescribir una cookie segura existente.
• HttpOnly: se omite de las API que no son HTTP, como document.cookie, pero sigue enviándose con fetch y XMLHttpRequest.
• SameSite: Strict solo se envía en solicitudes del mismo sitio; Lax también en navegaciones de nivel superior entre sitios con métodos seguros; None se envía en todos los casos y se rechaza a menos que también esté fijado Secure. MDN señala que algunos navegadores tratan la ausencia del atributo como Lax.
• Max-Age y Expires: Max-Age prevalece cuando ambos están presentes; ninguno de los dos convierte una cookie en cookie de sesión.
• Prefijos: un nombre que empieza por __Secure- solo se acepta con Secure; __Host- exige además Path=/ y ningún Domain, con lo que la cookie queda fijada a un único host. El borrador afirma que los puertos son la única parte del modelo de origen que las cookies __Host- siguen ignorando.

Por qué importa

Las cookies no están vinculadas a los orígenes. RFC 6265 establece que no ofrecen aislamiento ni por puerto ni por esquema; un subdominio puede fijar una cookie para su dominio padre y eclipsar la propia cookie del padre. La cabecera de solicitud Cookie no lleva ningún atributo, así que el servidor no puede saber cómo se fijó una cookie; los prefijos existen precisamente para darle esa certeza.

Cómo aplicarlo

• Cookie de sesión: __Host-session=<id>; Secure; HttpOnly; SameSite=Lax; Path=/; Max-Age=<seconds>.
• Omitir Domain a menos que los subdominios deban compartir la cookie, y en ese caso aceptar que cualquier subdominio puede sobrescribirla.
• SameSite=Strict para las cookies que solo se usan dentro de la aplicación; Lax para inicios de sesión que deben sobrevivir a la llegada por un enlace externo; None solo para uso incrustado entre sitios, siempre con Secure.
• No separar dos aplicaciones en un mismo host mediante Path; darles hosts separados.
• Eliminarla volviendo a fijarla con el mismo nombre, Domain y Path, y Max-Age=0.

Trampas

Un punto inicial en Domain se ignora, un punto final hace que el atributo se ignore. RFC 6265 dice que los agentes de usuario de uso general deberían soportar al menos 4096 bytes por cookie y 50 cookies por dominio; más allá de esos límites las cookies pueden descartarse en silencio. Dos servicios en distintos puertos de un mismo host ven las cookies del otro.