En cada nuevo proyecto, los equipos de desarrollo suelen tropezar con la misma discusión: ¿guardamos el token JWT en localStorage o en una cookie? Tras años de ciclos repetitivos, en Q2BSTUDIO hemos consolidado un patrón de autenticación que aplicamos de forma sistemática, ajustando solo los detalles que cada aplicación requiere (como el soporte para clientes móviles o consumidores de API de terceros con tokens Bearer). Este patrón no solo elimina la incertidumbre técnica, sino que cierra las puertas a vulnerabilidades comunes como XSS, CSRF o sesiones secuestradas por CORS mal configurado. En este artículo compartimos la estructura completa, las razones detrás de cada pieza y cómo migrar desde un sistema existente sin romper nada.
La decisión central: cookie httpOnly, nunca almacenamiento legible por JS La clave del patrón es emitir el token de sesión en una cookie con las flags httpOnly, Secure y SameSite=Lax, además de limitar su ámbito a un dominio que funcione en todos los subdominios. Esta cookie nunca toca localStorage, sessionStorage ni ninguna variable accesible desde JavaScript. El motivo es directo: cualquier dato que JavaScript pueda leer puede ser extraído por un payload XSS. Una cookie httpOnly es invisible para document.cookie y para cualquier script malicioso o inofensivo que se ejecute en la página. No es un lujo; es la diferencia entre “un bug XSS filtra la sesión” y “un bug XSS no filtra nada relacionado con la sesión”. En Q2BSTUDIO, cuando desarrollamos aplicaciones a medida, este principio es innegociable, ya que la protección de la sesión es la base de cualquier sistema con usuarios.
CSRF doble envío, solo donde se necesita La autenticación basada en cookies reintroduce el riesgo de CSRF que un token Bearer en un encabezado no tiene (el navegador adjunta cookies automáticamente, pero no encabezados personalizados). Para mitigarlo, usamos una segunda cookie legible por JavaScript que contiene un valor CSRF, y el frontend lo reenvía como encabezado de solicitud en cada mutación. El servidor comprueba que ambos coincidan. Esta protección solo es necesaria para operaciones de escritura — las lecturas no requieren validación CSRF — y no aplica en absoluto a clientes que usan exclusivamente tokens Bearer, ya que nunca fueron vulnerables a este ataque. En nuestros proyectos de ciberseguridad, implementar esta doble verificación es una de las primeras medidas que recomendamos para evitar que un atacante pueda ejecutar acciones en nombre de un usuario autenticado.
CORS: lista blanca, nunca comodín, especialmente con credenciales La combinación de Access-Control-Allow-Origin: * con credentials: true es peligrosa: permite que cualquier sitio secuestre las sesiones de tus usuarios. La solución es una lista blanca explícita de orígenes, con credentials: true y jamás un comodín ni un reflejo dinámico del encabezado Origin. En Q2BSTUDIO, al desplegar infraestructura en cloud AWS/Azure, configuramos los servicios para que el middleware CORS rechace cualquier origen no autorizado. Esto evita que un ataque de tipo “session riding” aproveche una configuración permisiva.
TOTP 2FA para cualquier rol privilegiado Cualquier usuario con permisos elevados (administradores, gestores, etc.) debe pasar por un flujo de autenticación de dos factores basado en TOTP (Time-based One-Time Password). El setup, enable y disable siguen un proceso estándar, y una vez activado, el 2FA es obligatorio en cada inicio de sesión. Implementarlo es barato comparado con el valor que aporta: una capa extra que protege cuentas con acceso a datos sensibles, operaciones financieras o configuraciones críticas. En entornos donde integramos BI / Power BI, por ejemplo, los dashboards de negocio suelen estar expuestos a perfiles que requieren esta protección adicional.
Migrar desde un sistema con tokens Bearer sin romper el funcionamiento actual La parte práctica que hace que este patrón sea adoptable en un proyecto en vivo es la migración en modo dual. Los guardias de autenticación aceptan tanto la cookie httpOnly como el encabezado Authorization; las comprobaciones CSRF solo se aplican en la ruta de la cookie. El endpoint de login sigue devolviendo el token en el cuerpo de la respuesta (para clientes que usan Bearer) mientras también establece la cookie. Ninguna integración existente se rompe, y el frontend puede migrar progresivamente. Así lo hemos hecho en múltiples proyectos de Q2BSTUDIO, desde plataformas de IA hasta sistemas que incorporan agentes IA para automatización de procesos.
Lista de verificación antes de dar por terminado el patrón En cada proyecto, verificamos los siguientes puntos: (1) El login establece realmente una cookie httpOnly (comprobando las cabeceras de respuesta, no solo que 'parece funcionar'). (2) Las solicitudes basadas en cookie funcionan sin necesidad de adjuntar manualmente el token. (3) Una mutación sin el encabezado CSRF es rechazada con 403, no aceptada silenciosamente. (4) Una solicitud desde un origen no permitido no recibe la cabecera Access-Control-Allow-Origin. (5) El logout elimina ambas cookies, no solo la sesión del lado servidor. Saltar cualquiera de estas comprobaciones convierte “implementamos protección CSRF” en “implementamos una cabecera CSRF que nadie valida”.
Lo que le diría a mi yo del pasado Decide el patrón de autenticación una vez, hazlo bien y reutilízalo. No reabras el debate localStorage vs cookie en cada nuevo proyecto. La combinación de CORS con comodín y credenciales es la forma más fácil de construir accidentalmente una vulnerabilidad de secuestro de sesión. Haz que sea imposible de enviar a producción, no solo que esté documentado como incorrecto. Un plan de migración que mantenga funcionando a los clientes antiguos es lo que realmente permite adoptar un patrón endurecido en una aplicación en vivo — las propuestas de “reescríbelo todo” mueren en las reuniones de planificación. En Q2BSTUDIO, aplicamos esta filosofía en cada desarrollo, garantizando que la seguridad no sea un añadido tardío sino un pilar desde el primer día.
