Definición
Una sesión es el estado que permite a un sistema recordar quién eres entre una petición y la siguiente.
Sin ella, cada página exigiría volver a identificarse, porque HTTP no recuerda nada por sí mismo. Ver cookie, que es el mecanismo habitual para transportarla.
Dos formas de hacerlo
Sesión en servidor. El servidor guarda los datos del usuario y le entrega un identificador aleatorio. El navegador devuelve ese identificador en cada petición y el servidor busca a quién corresponde.
Token firmado (JWT). El servidor entrega un token que contiene la información y va firmado. El servidor no guarda nada: verifica la firma y confía en el contenido.
| Sesión en servidor | Token firmado | |
|---|---|---|
| Dónde vive el estado | En el servidor | En el cliente |
| Cerrar sesión al instante | Sí, se borra y ya | Difícil: el token sigue siendo válido |
| Escalar a varios servidores | Necesita almacén compartido | Trivial |
| Tamaño en cada petición | Un identificador | El token entero |
| Revocar acceso | Inmediato | Requiere lista negra o caducidad corta |
La elección se reduce casi siempre a una pregunta: ¿necesitas poder expulsar a alguien ahora mismo? Si la respuesta es sí —un panel de administración, un sistema con datos sensibles— la sesión en servidor es más honesta. Los tokens son cómodos para APIs y para escalar, y su punto débil real es la revocación.
Cómo se roba una sesión
Conviene conocer los tres vectores, porque las defensas salen de ahí:
Robo de la cookie. Con un XSS, el JavaScript del atacante lee la cookie y suplanta al usuario. Se evita con HttpOnly.
Interceptación en tránsito. Si la conexión no va por HTTPS, cualquiera en la misma red puede leer el identificador.
Fijación de sesión. El atacante consigue que la víctima use un identificador que él conoce. Se evita regenerando el identificador al iniciar sesión — es la defensa más olvidada y la más barata.
Ejemplo práctico
En un panel de administración, la gestión de sesión decide más de la seguridad real que la fortaleza de la contraseña.
Lo que aprendí montando accesos: las cuatro medidas que de verdad cambian algo son sencillas y suelen faltar todas a la vez:
Regenerar el identificador al hacer login. Dos líneas, y cierra la fijación de sesión.
Caducidad por inactividad, no solo por tiempo absoluto. Un panel abierto en un ordenador compartido durante horas es un riesgo real.
Cookie con HttpOnly y Secure, siempre.
Poder cerrar todas las sesiones de un usuario desde el sistema. El día que alguien deja la empresa o pierde el portátil, esa función es la que se necesita — y es justo la que nadie construye hasta que hace falta.
El segundo aprendizaje, sobre el «recordarme»: es la función que más cómoda resulta y más riesgo introduce, porque alarga la vida de la sesión durante semanas. La forma sensata de plantearlo no es todo o nada, sino por niveles: recordar para navegar sí, y volver a pedir contraseña antes de una acción sensible — cambiar datos bancarios, dar de alta a un usuario, exportar la base de clientes.
Ese patrón —sesión larga para lo cotidiano, reautenticación para lo delicado— da comodidad sin regalar el castillo.
Y una advertencia sobre guardar cosas en el navegador: localStorage es accesible desde JavaScript, así que no es sitio para un token de sesión. Un XSS lo lee sin esfuerzo. Sirve para preferencias de interfaz, no para credenciales.
Errores comunes
- No regenerar el identificador al iniciar sesión.
- Cookie sin
HttpOnly. - Guardar el token en
localStorage. - Sesiones que no caducan nunca.
- No poder revocar el acceso de un usuario concreto.
- Meter datos sensibles en el token. Un JWT va firmado, pero no cifrado: cualquiera puede leer su contenido.
- Usar identificadores predecibles. Deben ser aleatorios y largos.
Cuándo revisarlo
Al construir cualquier acceso con usuarios, y siempre antes de exponer un panel a internet.
La pregunta que mide si está bien resuelto: si a un usuario le roban el portátil ahora mismo, ¿puedo cerrar su acceso en un minuto? Si la respuesta es no, ese es el primer arreglo.
