Por qué tener sesiones abiertas en tu app no es tan seguro como parece
En 2023, un hacker tomó el control de los canales de Linus Media Group, incluidos Linus Tech Tips, TechLinked y TechQuickie. Transmitió vídeos fraudulentos sobre criptomonedas usando la imagen de Elon Musk y dejó a la empresa fuera de sus propios canales durante horas. Lo hizo sin siquiera conocer la contraseña.
Cómo pasó eso?
Un empleado de Linus Media Group abrió un PDF con una propuesta de patrocinio. Resulta que solo parecía un PDF, pero era un ejecutable malicioso. El malware robó datos de sesión del navegador y el hacker los reutilizó para entrar como un usuario que ya había iniciado sesión. La propia Linus Tech Tips explicó el incidente.
Eso se llama un secuestro de sesión. Si construyes con IA, hay una lección incómoda detrás: una contraseña robusta y la autenticación en dos pasos no bastan si tu aplicación permite que una sesión siga siendo válida durante tiempo indefinido.
Una cookie de sesión, explicada sin jerga
Cuando inicias sesión en una aplicación, el servidor no te pide la contraseña en cada click que haces. Después de verificar quién eres, entrega al navegador una prueba temporal de que ya has iniciado sesión.
Muchas veces esa prueba viaja en una cookie. Piensa en ella como en una acreditación de acceso: el navegador la presenta cada vez que pide algo al servidor y el servidor responde: “vale, esta persona ya está autenticada”.
El problema es sencillo: la aplicación puede comprobar que esa acreditación es válida, pero no sabe si la está usando el dueño original o alguien que la ha robado.
Si alguien la copia y sigue siendo válida, puede presentarla desde otro ordenador y acceder con tu usuario. No necesita conocer tu contraseña ni completar de nuevo el segundo factor de autenticación.
No solo existen cookies, una sesión también puede depender de tokens, credenciales o datos de autenticación almacenados en el navegador. La idea importante es la misma: si algo prueba que el usuario ya inició sesión, hay que asumir que también puede ser robado.
Por qué esto debería importarte
Si estás construyendo una app o web app con herramientas de IA integrada, es fácil centrarse en conseguir que haya un login que funcione y dar por resuelto el problema.
Pero “el usuario puede iniciar sesión” no es lo mismo que “el ciclo de vida de su sesión es seguro”.
Las preguntas importantes llegan después:
- Cuánto tiempo sigue siendo válida una sesión? - Qué ocurre realmente al pulsar “cerrar sesión”? - Puede el usuario cerrar sesiones desde otros dispositivos? - Qué sucede si cambia la contraseña? - Cómo revocas una cookie robada?
Si no tienes respuestas concretas, puede que tus sesiones duren más de lo necesario o que no puedas revocarlas cuando haga falta.
La escala del problema
No es un caso aislado. El informe de SpyCloud (una empresa de ciberseguridad que analiza credenciales, cookies y otros datos robados) de 2026 recoge 8.600 millones de cookies y artefactos de sesión robados durante 2025, asociados a infecciones por malware tipo infostealer.
Según el mismo informe, también identifica 6,2 millones de cookies de autenticación o credenciales vinculadas a herramientas de IA: datos robados que podían dar acceso a cuentas de servicios de IA.
Hay un detalle especialmente relevante: los datos robados se reutilizan y redistribuyen. No siempre son robos nuevos; a menudo son el mismo acceso comprometido circulando durante meses.
Una sesión sin una caducidad bien diseñada no es un riesgo puntual. Es una puerta que puede quedarse abierta mucho después de que el incidente ocurra.
El checklist que puedes revisar hoy
1. Define una caducidad por inactividad y otra caducidad por superar un tiempo
No es suficiente con que la sesión caduque “algún día”. Configura:
- Un límite por inactividad: si el usuario no hace nada durante cierto tiempo, la sesión termina.
- Un límite máximo: aunque siga activo, debe volver a autenticarse tras un periodo máximo.
El tiempo depende de tu aplicación. No es lo mismo una app de notas que un panel con pagos, datos personales o permisos de administración. Lo esencial es que ambas caducidades se apliquen en el servidor, no solo en el navegador.
2. Haz que cerrar sesión invalide el acceso en el servidor
Borrar una cookie en el navegador no es suficiente.
Si alguien robó esa cookie antes del cierre de sesión, podrá seguir usándola si el servidor aún considera válida la sesión. Al cerrar sesión, tu backend debe hacer que esa sesión deje de funcionar también en el servidor. Así, aunque un atacante tuviera una copia de la cookie, ya no podrá usarla.
3. Protege las cookies correctamente
Si tu sesión usa cookies, revisa como mínimo:
HttpOnly: evita que el código de la página pueda leer la cookie directamente.Secure: hace que el navegador solo la envíe mediante HTTPS.SameSite=LaxoSameSite=Strict: limita que otras webs puedan provocar peticiones usando esa cookie.
Esto no protege frente a un malware que ya controla el ordenador de la víctima. Sí reduce otras vías frecuentes de robo o abuso.
4. Revoca las sesiones al cambiar la contraseña
Si un usuario cambia la contraseña porque sospecha que su cuenta ha sido comprometida, mantener vivas las sesiones anteriores es una mala señal.
El cambio de contraseña debería invalidar las sesiones activas y cualquier credencial persistente asociada. Como mínimo, permite al usuario elegir entre conservar la sesión actual y cerrar el resto o cerrar todo.
5. Permite cerrar sesión en todos los dispositivos
Incluye una opción clara: “Cerrar sesión en todos los dispositivos”.
Idealmente, acompáñala de una lista de sesiones activas con dispositivo aproximado, ubicación aproximada y última actividad. Así el usuario puede detectar algo raro y expulsar esa sesión sin tener que escribir a soporte.
6. Registra anomalías, pero no dependas solo de ellas
Una sesión nueva desde un dispositivo o país inusual merece atención. Regístrala, avisa al usuario cuando el riesgo sea alto y exige una nueva autenticación para acciones sensibles.
Pero no bases toda tu defensa en dirección IP o navegador: un hacker puede compartir red con la víctima, usar una VPN o imitar parte de la información del navegador. Son señales útiles, no pruebas definitivas.
7. No guardes información sensible en el navegador
Evita guardar permisos críticos, datos personales o información de pago dentro de la sesión que se almacena en el navegador.
8. Pide una nueva verificación para operaciones críticas
Cambiar el correo, modificar permisos, exportar datos, crear claves API, cambiar datos de pago o borrar una cuenta deberían requerir una autenticación reciente.
Una sesión robada es mucho menos útil si no puede ejecutar las acciones que causan más daño.
Lo que este checklist no resuelve
El caso de Linus Tech Tips empezó en un ordenador comprometido por malware. Estas medidas no impiden, por sí solas, que alguien abra un archivo malicioso ni desinfectan un equipo infectado.
Lo que sí hacen es limitar el daño:
- reducen el tiempo útil de una sesión robada;
- permiten revocarla rápidamente;
- dificultan que un atacante mantenga el acceso;
- protegen las acciones de alto impacto.
La seguridad no consiste en asumir que nadie cometerá un error. Consiste en diseñar el sistema para que un error no se convierta automáticamente en una catástrofe.
La idea que conviene recordar
A Linus Tech Tips no le entraron por una contraseña débil. Reutilizaron una sesión que ya era válida.
Por eso, al revisar la autenticación de tu app, no te quedes solo en la pantalla de login. Pregunta cuánto dura una sesión, cómo se revoca y qué puede hacer mientras sigue viva.
Ahí está la diferencia entre una aplicación que parece segura y una que aguanta mejor cuando algo inevitablemente sale mal.