¿Qué hacen los atributos de cookie HttpOnly, Secure y SameSite?

Una cookie de sesión es un token al portador: quien la posee es el usuario. Por eso los atributos que le asignes determinan lo difícil que le resulta a un atacante robar, interceptar o abusar de ese token. Tres atributos hacen la mayor parte del trabajo, y cada uno corresponde a una amenaza distinta.

HttpOnly — bloquea el acceso por script

HttpOnly indica al navegador que no exponga la cookie a JavaScript. document.cookie no puede leerla. Esta es la mitigación clave frente al robo de sesión basado en XSS: incluso si un atacante inyecta script, no puede exfiltrar la cookie de sesión. Nótese que no previene el XSS en sí — el script inyectado todavía puede hacer peticiones autenticadas como el usuario — pero impide que la cookie salga del navegador, lo que contiene el daño.

Secure — solo HTTPS

Secure indica al navegador que envíe la cookie solo por HTTPS. Sin él, una única petición http:// accidental (o forzada por un atacante) transmitiría la cookie de sesión en texto claro, donde un atacante de red puede capturarla. Combinado con HSTS, esto cierra la vía de interceptación de red.

SameSite — envío entre sitios

SameSite controla si la cookie acompaña a las peticiones originadas en otros sitios:

• Strict — nunca se envía entre sitios (la protección CSRF más fuerte, pero puede interrumpir enlaces entrantes a páginas autenticadas).
• Lax — se envía en navegaciones de nivel superior pero no en subpeticiones/POST entre sitios; un buen valor por defecto que bloquea el CSRF clásico.
• None — siempre se envía, y requiere Secure.

Cinturón y tirantes: prefijos de nombre

El prefijo __Host- permite al navegador imponer que una cookie sea Secure, de ruta / y no esté vinculada a un dominio — una protección frente a trucos de fijación de cookie / subdominio.

Los entrevistadores buscan la correspondencia atributo-amenaza (HttpOnly/robo por XSS, Secure/escucha, SameSite/CSRF) y el matiz de que HttpOnly limita el impacto del XSS en lugar de prevenirlo.