Cookies seguras: getCookie, setCookie y deleteCookie

Una sesión sellada es cómoda porque esconde la cookie, pero por debajo siempre hay una cookie cruda, y hay estado —una preferencia de tema, un token de un tercero, un identificador de dispositivo— que quieres manejar sin todo el aparato de sellado. Para eso SolidStart reexpone los helpers de cookies de vinxi: getCookie para leer, setCookie para escribir con sus atributos, deleteCookie para caducar. No son azúcar: cada opción que les pasas —httpOnly, secure, sameSite, path, maxAge— decide cuándo y a quién entregará el navegador esa credencial. Dominar esos atributos es dominar la superficie de ataque de tu autenticación, porque una cookie mal configurada es una puerta que creías cerrada.

Los tres helpers de vinxi/http

Los tres helpers reciben como primer argumento el evento nativo de h3 —el que representa la petición viva— y actúan sobre sus cabeceras Cookie y Set-Cookie. getCookie devuelve el valor o undefined; setCookie programa una cookie con sus opciones; deleteCookie emite una cookie ya caducada para que el navegador la olvide.

import { getCookie, setCookie, deleteCookie } from "vinxi/http";
// getCookie(evento, nombre)                -> string | undefined
// setCookie(evento, nombre, valor, opciones)
// deleteCookie(evento, nombre, opciones)

La firma pide el evento porque una cookie no existe en el vacío: pertenece a una petición y a una respuesta concretas. De ahí que estos helpers, como las sesiones, solo tengan sentido en el servidor, donde esas cabeceras existen.

Los atributos que hacen segura una cookie

Escribir una cookie sin atributos es dejar una credencial a la intemperie. Cada opción cierra un vector de ataque distinto, y una cookie de autenticación seria los combina todos.

setCookie(evento, "token", valorFirmado, {
  httpOnly: true,   // invisible a document.cookie: el XSS no puede robarla
  secure: true,     // el navegador solo la envia por HTTPS
  sameSite: "lax",  // no viaja en peticiones cross-site peligrosas: frena CSRF
  path: "/",        // alcance: toda la app
  maxAge: 60 * 60 * 24 * 7, // vida en segundos; sin esto seria de sesion
});

• httpOnly la oculta del JavaScript de la página: aunque un atacante inyecte un script (XSS), no podrá leer document.cookie para exfiltrar el token. Es la defensa número uno de cualquier credencial.
• secure prohíbe que la cookie viaje por HTTP en claro; sin ella, una red hostil la vería.
• sameSite controla si la cookie acompaña a peticiones iniciadas desde otro sitio. lax —valor por defecto sensato— la envía en navegaciones de nivel superior pero no en peticiones incrustadas; strict la retiene incluso al llegar desde un enlace externo; none la manda siempre, pero obliga a secure y solo se usa en flujos cross-site legítimos.

Cookies desde funciones de servidor y desde middleware

El único matiz práctico es de dónde sacas el evento. En middleware ya lo tienes: event.nativeEvent. En una función de servidor lo recuperas con getRequestEvent de solid-js/web y accedes a su .nativeEvent.

// Desde una funcion de servidor
import { getRequestEvent } from "solid-js/web";
import { getCookie, setCookie } from "vinxi/http";

export async function fijarTema(tema: "claro" | "oscuro") {
  "use server";
  const event = getRequestEvent()!;
  setCookie(event.nativeEvent, "tema", tema, {
    secure: true,
    sameSite: "lax",
    maxAge: 60 * 60 * 24 * 365, // un ano
    path: "/",
    // sin httpOnly: aqui si queremos que el cliente lea el tema
  });
}

export async function leerTema() {
  "use server";
  const event = getRequestEvent()!;
  return getCookie(event.nativeEvent, "tema") ?? "claro";
}

// Desde middleware
import { createMiddleware } from "@solidjs/start/middleware";
import { getCookie } from "vinxi/http";

export default createMiddleware({
  onRequest: (event) => {
    const tema = getCookie(event.nativeEvent, "tema"); // ya tienes el evento
    event.locals.tema = tema ?? "claro";
  },
});

Observa el contraste deliberado: la cookie de tema no lleva httpOnly, porque queremos que el cliente la lea para pintar sin parpadeo; la cookie de sesión de la lección anterior sí lo lleva, porque su valor es una credencial que el cliente nunca debe tocar. El atributo no es un adorno: codifica quién tiene derecho a leer.

flowchart TD
A[setCookie con atributos] --> B{httpOnly}
B -->|si| C[oculta a document.cookie: frena XSS]
A --> D{secure}
D -->|si| E[solo por HTTPS]
A --> F{sameSite}
F -->|lax o strict| G[no viaja cross-site: frena CSRF]
style C fill:#a6e3a1,color:#11111b
style E fill:#a6e3a1,color:#11111b
style G fill:#a6e3a1,color:#11111b

El prefijo __Host- y el candado completo

Para una cookie de sesión, el endurecimiento máximo es nombrarla con el prefijo __Host-. El navegador solo acepta una cookie así si viene con secure, con path a la raíz y sin atributo domain, lo que la ata a un único host y la blinda contra ataques donde un subdominio comprometido fija cookies para el dominio padre. Es una garantía que el propio navegador hace cumplir.

setCookie(evento, "__Host-sesion", valorSellado, {
  httpOnly: true,
  secure: true,
  sameSite: "lax",
  path: "/",     // obligatorio para __Host-
  // sin domain: obligatorio para __Host-
});

Para borrar una cookie, deleteCookie debe recibir los mismos path y domain con que se creó; si no coinciden, el navegador la trata como otra cookie distinta y la original sobrevive. Y distingue la cookie persistente —con maxAge o expires, que aguanta cierres del navegador, la que quieres para un «recuérdame»— de la cookie de sesión —sin ninguno de los dos, que muere al cerrar la pestaña, la adecuada para un acceso efímero—.