Resumen

  • RFC 10025 define cómo un navegador puede almacenar y devolver un estado Cookie dentro de un alcance. El significado de su valor y el estado vivo de la sesión los decide la aplicación.
  • Secure, HttpOnly, SameSite, host-only, Domain y los prefijos de nombre acotan condiciones específicas. Ninguno certifica que una orden sea actual, voluntaria, permitida o completada.
  • La arquitectura sólida registra por separado la emisión de sesión, la evaluación del contexto, la autorización de la acción, la frescura, el compromiso y el resultado verificable.

Una empresa descubre dos solicitudes idénticas para modificar el destino de una factura. Ambas tienen la misma cookie y ambas recibieron una respuesta de aceptación. El problema ya no es sólo de ciberseguridad; es de contabilidad de decisiones. ¿La segunda fue un reintento después de una caída de red? ¿Una repetición contra un estado de cuenta distinto? ¿La primera quedó en una cola y la segunda llegó al proveedor? La cookie está presente en todos esos relatos y no elige ninguno.

Eso no la hace inútil. La coloca en su sitio.

RFC 10025 trata Cookie y Set-Cookie como mecanismo de estado HTTP. Indica qué datos de almacenamiento y selección puede considerar un agente de usuario. Deja el valor semántico a la aplicación. El protocolo no sabe si una cadena opaca corresponde a una sesión, a una preferencia, a una cesta o a un identificador que el servidor ya revocó. Por tanto, cualquier sistema que lea “Cookie presente” como “acción aprobada” está añadiendo conclusiones que no provienen del RFC ni de la cabecera.

Alcance no es autoridad sobre la operación

La regla host-only es especialmente útil porque limita un cookie sin atributo Domain al host que lo emitió. El atributo Domain, si se acepta, permite una selección más amplia. El tratamiento de sufijos públicos evita algunos ámbitos demasiado generales. Cada una de esas condiciones responde a una pregunta de distribución: dónde puede devolver el navegador un valor. No responde a la pregunta de gobierno: qué servicio, rol o flujo puede usar esa sesión para cambiar un objeto concreto.

El camino ofrece otra pista falsa frecuente. Ayuda a que el agente de usuario seleccione cookies en solicitudes particulares, pero no es un muro de autorización. Si dos valores comparten nombre o una ruta recibe una combinación inesperada, el servidor debe tener una interpretación consciente y comprobable. Dejar que el orden de una cabecera resuelva una identidad crítica es esconder una política dentro de un detalle de formato.

Secure reduce la devolución a conexiones que el navegador considera seguras. HttpOnly reduce el acceso mediante interfaces no HTTP. Son defensas importantes. No vuelven al navegador una prueba de intención humana. Un cookie HttpOnly todavía puede viajar con una solicitud HTTP aplicable, aunque un script no pueda leerlo. La autoridad sigue siendo ambiental: el navegador puede presentar un valor relevante porque otra parte consiguió dirigir una solicitud hacia un recurso.

La palabra “ambiental” evita una equivocación costosa. El peligro no exige siempre extraer un secreto. A veces basta con que el secreto permanezca en el navegador y la aplicación trate su transporte automático como una aprobación.

SameSite y los límites de una defensa útil

Las modalidades Strict y Lax reducen determinados retornos entre sitios. Es correcto emplearlas, pero es incorrecto convertirlas en un certificado general contra CSRF. RFC 10025 describe Lax como defensa en profundidad para ciertos casos, y el comportamiento de compatibilidad de cookies por defecto puede permitir una cookie reciente en una navegación superior no segura desde el punto de vista del método.

La pregunta de diseño debe ser más concreta: ¿qué evidencia de contexto necesita esta acción? Un cambio de correo de recuperación puede exigir un token ligado a la vista, una comprobación de origen, autenticación reciente y aviso al canal anterior. Un desembolso puede necesitar además límites, segregación de funciones y una confirmación independiente. No son adornos que se puedan sustituir por un atributo. Son propietarios distintos de hechos distintos.

Los prefijos lo demuestran. __Secure- demanda origen seguro y Secure. __Host- exige también Path=/ y prohíbe Domain. El navegador puede rechazar una emisión que incumpla esas condiciones. No consulta si el titular perdió acceso, si cambió el riesgo de la cuenta, si la operación supera un límite o si un segundo aprobador firmó. La fortaleza del prefijo es su frontera limitada.

La aceptación de sesión es una decisión renovable

Después de interpretar la cabecera, el servidor debe resolver una sesión viva. Puede rechazarla por caducidad, cierre explícito, recuperación de cuenta, rotación posterior, cambio de privilegio o señal de riesgo. El hecho de que un navegador conserve un valor no contradice ese rechazo. Es el diseño correcto de dos realidades: almacenamiento cliente y aceptación de servidor.

La fijación de sesión no se corrige inspeccionando la cookie con más cuidado. Se corrige impidiendo que un identificador anterior atraviese un salto de autoridad sin rotación y sin nueva evaluación. La evidencia útil es el registro de emisión, la relación entre identificadores antes y después, la invalidación y la negativa posterior. Una cadena de texto no puede declarar por sí misma que sigue mereciendo confianza.

Luego viene la autorización. Una sesión reconocida puede permitir ver un saldo sin permitir cambiar un beneficiario. El sistema debe valorar sujeto, objeto, rol, condiciones temporales, mandato, límites y, cuando sea necesario, confirmación. Esa es la capa donde se decide si alguien puede actuar; no es un efecto lateral de la capa que entrega estado al navegador.

También conviene separar compromiso y resultado. Una respuesta 200 puede significar que un proceso recibió la orden, que una transacción local terminó o que una tarea quedó pendiente. No prueba liquidación, entrega, cambio en un dispositivo ni recepción por una contraparte. El identificador de la acción debe atravesar el sistema hasta una observación compatible con la consecuencia prometida.

El registro que permite reparar sin inventar

En emisión, guarde una referencia segura de sesión, el evento que la originó, el sujeto, el alcance y la política de rotación o revocación. En recepción, guarde host, ruta, sesión seleccionada y el resultado de controles de contexto, incluidos rechazos. En autorización, guarde la operación solicitada, el objeto, la regla, las restricciones y cualquier aprobación adicional. En efecto, guarde intento, estado de compromiso, referencia posterior y reconciliación.

No se trata de convertir cada clic en un proceso de alto riesgo. Se trata de impedir que una sola señal cubra hechos que no puede observar. Las acciones ordinarias pueden seguir siendo rápidas; las irreversibles deben poder explicar qué las autorizó y qué ocurrió después.

Fuentes