HTTP Cookies Cómo crear y analizarlos correctamente

Los HTTP cookies están por todas partes. Cada sesión de inicio de sesión, cada carrito de compras y cada herramienta de análisis depende de ellos. Sin embargo, la mayoría de los desarrolladores copian y pegan una cabecera y se van sin entender qué hacen realmente los atributos — o qué ocurre cuando se configuran mal. Set-Cookie Este guía cubre la anatomía de las cookies, todos los atributos significativos, cómo analizar cadenas de cookies y por qué

es tu defensa contra CSRF. Si quieres comenzar de inmediato, prueba el SameSite IO Tools Parser de Cookies Constructor de Cookies o el Qué es realmente una cookie.

Cuando un servidor desea establecer una cookie, envía una

cabecera de respuesta: Set-Cookie El navegador almacena esto y lo envía de vuelta en solicitudes posteriores como:

Set-Cookie: sessionId=abc123; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=86400

Esa es la totalidad del mecanismo. La complejidad radica en esos atributos.

Cookie: sessionId=abc123

Anatomía de la cookie: Desglose de la cadena

Una cadena de cookie sigue un formato consistente:

el par aparece primero. Todo lo que sigue después de la primera semicolon es una directiva para el navegador — el servidor nunca ve estos atributos en la

name=value; attribute1; attribute2=attributeValue; ...

El name=value cabecera que recibe. Cookie Los atributos de seguridad que debes configurar correctamente

HttpOnly

impide que JavaScript lea la cookie mediante

HttpOnly . Esto es una defensa directa contra ataques XSS que roben los tokens de sesión. document.cookieCualquier cookie que autentique a un usuario debe tener

Set-Cookie: sessionId=abc123; HttpOnly

. No hay una buena razón para no hacerlo. HttpOnlysignifica que el navegador solo envía la cookie en conexiones HTTPS. Sin ella, la cookie viaja en texto plano sobre HTTP y puede ser interceptada. En producción, las cookies de sesión siempre necesitan

Seguro

Secure . En desarrollo local sobre Secure, puedes omitirla — los navegadores hacen una excepción para localhost. http://localhostcontrola cuándo el navegador incluye una cookie en solicitudes entre sitios. Esta es la principal defensa contra ataques CSRF. Tres valores:

SameSite

SameSite — la cookie nunca se envía en solicitudes entre sitios. Es la más segura, pero los usuarios que hagan clic en un enlace de correo llegan deslogueados (la cookie no se envía en esa navegación inicial).

• Strict — la cookie se envía en navegaciones de nivel superior (solicitudes GET) desde sitios externos, pero no en solicitudes incrustadas entre sitios o en solicitudes POST entre sitios. Este es el valor predeterminado del navegador para las cookies sin un atributo explícito
• Lax . SameSite — la cookie se envía en todas las solicitudes entre sitios. Necesario para cookies de terceros (flujo de OAuth, widgets incrustados). Debe ir acompañado de
• None . Si envías Secure.

# Third-party / cross-site cookie (e.g., OAuth callback)
Set-Cookie: token=xyz; SameSite=None; Secure

, los navegadores modernos rechazan la cookie por completo. Para la mayoría de las cookies de sesión, usa SameSite=None sin Secure— equilibra la seguridad con una experiencia de inicio de sesión útil. SameSite=Lax Alcance: Dominio y Ruta

El atributo especifica qué nombres de dominio reciben la cookie.

Dominio

El Domain Con

Set-Cookie: user=alice; Domain=example.com

, la cookie se envía a Domain=example.comy a todos los subdominios ( example.com ). Sin un atributoapi.example.com, app.example.com, la cookie solo se envía al origen exacto que la estableció — no a subdominios. Domain Concepto común: establecer

no Domain=example.com limita la cookie a solo no . Amplía el alcance para incluir subdominios. Omita el atributo si deseas una cookie de solo un dominio. example.comlimita las rutas que desencadenan que la cookie se envíe.

Camino

Path Esta cookie solo acompaña a las solicitudes a

Set-Cookie: adminToken=xyz; Path=/admin

y a las rutas bajo ella. Una solicitud a /admin no la incluiría. El valor predeterminado es / o /api , lo que significa todas las rutas. /Max-Age vs Expires

Ambos controlan cuándo expira una cookie. Prefiere

toma una fecha absoluta en formato de fecha HTTP. Esto es relativo al reloj del cliente, que no puedes controlar. Max-Age.

• Expires toma un número de segundos desde ahora:
• Max-Age por 24 horas. Relativo a la intención del servidor, no al reloj del cliente. Max-Age=86400 Cuando ambos están presentes,

toma prioridad. Una cookie sin ninguno de estos atributos es una Max-Age cookie de sesión — desaparece cuando se cierra el navegador. Referencia de atributos de cookie

Atributo

Qué hace	Bloquea el acceso de JavaScript a la cookie	Por defecto	Recomendación
HttpOnly	No establecido	Siempre establecido para cookies de autenticación	Transmisión solo en HTTPS
Secure	Siempre establecido en producción	Siempre establecido para cookies de autenticación	Controla el envío entre sitios
SameSite	Lax (navegadores modernos)	Lax para sesiones; Ninguno + Seguro para terceros	Establece el alcance del dominio
Domain	Solo el dominio actual	Omitir si no se necesita acceso entre subdominios	Establece el alcance de la ruta
Path	Dejar como / a menos que se necesite aislar tokens de administración	/	Segundos hasta la expiración
Max-Age	Cookie de sesión	Preferir sobre Expires	Fecha absoluta de expiración
Expires	Usar Max-Age en su lugar	Preferir sobre Expires	Configuración de cookies en código

Node.js (Express)

Python (FastAPI)

app.post('/login', (req, res) => {
  // ... verify credentials ...

  res.cookie('sessionId', token, {
    httpOnly: true,
    secure: process.env.NODE_ENV === 'production',
    sameSite: 'lax',
    maxAge: 86400 * 1000, // milliseconds in Express
    path: '/',
  });

  res.json({ ok: true });
});

Análisis manual de cabeceras de cookie

from fastapi import FastAPI, Response

app = FastAPI()

@app.post("/login")
def login(response: Response):
    # ... verify credentials ...

    response.set_cookie(
        key="sessionId",
        value=token,
        httponly=True,
        secure=True,
        samesite="lax",
        max_age=86400,
        path="/",
    )
    return {"ok": True}

La cabecera que recibe el servidor contiene solo

El Cookie pares, separados por name=value . Para analizarlo manualmente: dividir por ; :

Cookie: sessionId=abc123; theme=dark; lang=en

(semicolon + space), luego dividir cada par por el ; primero solo. Casos especiales que vale la pena conocer: = Los valores pueden contener

• (cadenas base64 que comúnmente lo hacen) — siempre dividir por el primer = solo = Los nombres de las cookies son sensibles a mayúsculas y minúsculas
• El espacio alrededor del separador puede variar — eliminar espacios de ambos lados defensivamente
• En lugar de escribir tú mismo la lógica de división, usa el

para decodificar cualquier Constructor de Cookies cabecera y inspeccionar cada valor, o el Cookie IO Tools Constructor de Cookies para construir una cabecera válida de cookie con los atributos correctos. Cookies y CSRF Set-Cookie El ataque de Cross-Site Request Forgery explota el hecho de que los navegadores incluyen automáticamente cookies en solicitudes a un dominio, incluso cuando se inician desde un sitio diferente. Una página maliciosa en

puede enviar un formulario a

, y si el usuario está autenticado, el navegador envía su cookie de sesión junto con la solicitud falsa. evil.com defiende la mayoría de los vectores CSRF porque las solicitudes entre sitios — el patrón típico de ataque — no incluyen la cookie. bank.com/transferes aún más exhaustiva pero puede afectar la usabilidad.

SameSite=Lax Los tokens CSRF permanecen válidos como defensa en profundidad, especialmente para operaciones de alto riesgo y cuando SameSite=Strict es requerido para el contexto de terceros. Las dos defensas se complementan.

HTTP Cookies: Cómo construir y analizarlas correctamente 2 SameSite=None HTTP Cookies: Cómo construir y analizarlas correctamente 1

También te puede interesar