Saltar al contenido

Guía completa de indicadores de seguridad de Cookie | Secure / HttpOnly / SameSite / __Host-

Categoría: Seguridad Web
Este artículo está disponible actualmente solo en japonés. Estamos trabajando en las traducciones.

Las cookies son el mecanismo más comúnmente utilizado para la gestión de sesiones en aplicaciones web, pero una configuración incorrecta puede llevar a ataques como <strong>secuestro de sesión</strong>, <strong>CSRF</strong> (falsificación de solicitud entre sitios) y robo de tokens a través de <strong>XSS</strong>. Este artículo explica el significado de cuatro banderas esenciales (<code>Secure</code> / <code>HttpOnly</code> / <code>SameSite</code> / prefijo <code>__Host-</code>) que deben aplicarse a las cookies y clarifica los errores comunes en la implementación.

Estructura del encabezado Set-Cookie

Cuando el servidor establece una Cookie en el navegador, devuelve un encabezado como el siguiente en la respuesta HTTP.

Set-Cookie: session_id=abc123; Path=/; Domain=example.com; Expires=Wed, 22 Apr 2026 10:00:00 GMT; Secure; HttpOnly; SameSite=Lax

Hay múltiples atributos separados por puntos y comas, que se pueden dividir ampliamente en los siguientes dos tipos.

  1. <strong>Atributos de alcance</strong>: Path / Domain / Expires / Max-Age — Determina cuándo y dónde se envía una cookie
  2. <strong>Atributos de seguridad</strong>: Secure / HttpOnly / SameSite — Restringir transmisión y acceso

Secure — Enviar solo a través de HTTPS

Una cookie con el atributo <code>Secure</code> es enviada al servidor por el navegador <strong>solo sobre conexiones HTTPS</strong>. Sin él, cuando una víctima accede al sitio a través de <code>http://</code>, la cookie fluye en texto plano y los ID de sesión pueden ser robados mediante ataques intermediarios (Man-in-the-Middle).

<strong>Regla de oro:</strong> Siempre adjúntalo a las cookies de autenticación. En desarrollo local, localhost permite cookies seguras incluso sin HTTPS, pero si asumes HTTPS en producción, no hay problema.

HttpOnly — No Accesible desde JavaScript

agregar <code>HttpOnly</code> previene la lectura mediante <code>document.cookie</code>. Esto previene que JavaScript inyectado por ataques XSS robe cookies.

Dado que XSS sigue siendo una vulnerabilidad posible, considere la bandera HttpOnly como esencial para las cookies de sesión. Si su código JavaScript necesita leer valores de cookies (por ejemplo, tokens CSRF), el enfoque estándar es <strong>crear una cookie separada de solo lectura</strong> o pasar el valor a través de <strong>etiquetas &lt;meta&gt;</strong>.

SameSite — Control de transmisión en solicitudes entre sitios

El atributo SameSite es fundamental para la protección CSRF. Los valores son los siguientes tres:

ValorComportamientoProtección CSRF
StrictNo envíe a solicitudes entre sitios en absoluto (incluso al venir desde enlaces externos)El más potente
<code>Lax</code> (predeterminado)Enviar solo en navegación GET de nivel superior (clics en enlaces OK, formularios POST NG)Fuerte
NoneSe envía con todas las solicitudes entre sitios (Secure requerido)Ninguno

Los navegadores modernos desde 2020 tratan SameSite sin especificar como <code>Lax</code>, por lo que obtiene protección CSRF mínima incluso sin especificación explícita. Sin embargo, es mejor configurarlo explícitamente para aclarar su intención.

Al usar <code>SameSite=None</code> con integración SSO o incrustación de iframe, <strong>debe agregar Secure también</strong>—este es un requisito de los navegadores modernos. Las cookies con <code>SameSite=None</code> pero sin Secure son rechazadas por los navegadores.

Prefijos __Host- / __Secure-

Cuando el nombre de una Cookie comienza con <code>__Host-</code>, el navegador impone las siguientes tres condiciones.

  • <code>Secure</code> es obligatorio
  • no debe incluir el atributo <code>Domain</code> (es decir, solo el host exacto que envió la solicitud)
  • <code>Path=/</code> es obligatorio

Estos proporcionan garantías sólidas: "no puede ser anulado desde otros subdominios" y "las cookies no pueden ser colocadas mediante suplantación del encabezado Host." Para cookies de sesión, es más robusto añadir un prefijo como <code>__Host-session</code>.

El otro prefijo <code>__Secure-</code> solo aplica la marca Secure obligatoria (sin restricciones de Domain / Path).

Límite de 4096 bytes

El valor de la Cookie se recomienda que sea <strong>un total de 4096 bytes</strong> según RFC 6265. Si pones JSON grandes o matrices en una Cookie y excedes este límite, el navegador puede truncarlas silenciosamente. La mejor práctica es almacenar datos grandes en sesiones del lado del servidor e incluir solo el ID de sesión en la Cookie.

Ejemplo de implementación: Cookie de sesión de autenticación

Una Cookie de autenticación configurada correctamente se ve así:

Set-Cookie: __Host-session=eyJ0eXAi...; Path=/; Max-Age=3600; Secure; HttpOnly; SameSite=Lax
  • <code>__Host-</code>: Previene la contaminación de subdominios y la suplantación de host
  • <code>Path=/</code>: Accesible en todo el sitio
  • <code>Max-Age=3600</code>: Expira en 1 hora
  • <code>Secure</code>: Se envía solo a través de HTTPS
  • <code>HttpOnly</code>: No accesible desde JavaScript
  • <code>SameSite=Lax</code>: No se envía en solicitudes POST entre sitios (protección CSRF)

Ejemplo de PHP (Laravel)

// config/session.php
return [
    'secure'     => true,      // Secure フラグ
    'http_only'  => true,      // HttpOnly フラグ
    'same_site'  => 'lax',    // SameSite=Lax
    'path'       => '/',
    'cookie'     => '__Host-session',
];

Ejemplo de Node.js (Express)

const session = require('express-session');

app.use(session({
  name: '__Host-session',
  secret: process.env.SESSION_SECRET,
  cookie: {
    secure:   true,
    httpOnly: true,
    sameSite: 'lax',
    path:     '/',
    maxAge:   3600 * 1000,
  },
}));

Cómo verificar la configuración de cookies en un sitio existente

Puede verificar instantáneamente si las cookies en su sitio o sitios de terceros están configuradas correctamente usando la <a href="/ja/check/cookies/">herramienta de inspección de cookies de DevLab</a>. Simplemente ingrese una URL, y la herramienta analiza todos los encabezados Set-Cookie devueltos y muestra diagnósticos como los siguientes.

  • Presencia de Secure / HttpOnly / SameSite en cada cookie
  • Violaciones como SameSite=None sin Secure
  • Coherencia del prefijo __Host-
  • Advertencia de exceso de 4096 bytes
  • Resumen general (tasa Secure / tasa HttpOnly / distribución SameSite)

Resumen

Los indicadores de seguridad de Cookie no deben establecerse arbitrariamente, sino configurarse basándose en la comprensión de escenarios de ataque y medidas de contramedida apropiadas. Como mínimo, las Cookies de sesión de autenticación de producción deben incluir <strong>Secure + HttpOnly + SameSite + prefijo __Host- + Max-Age corto</strong>. Para revisar la configuración en sitios existentes, recomendamos utilizar la <a href="/ja/check/cookies/">herramienta de inspección de Cookie</a>.