Autenticación segura en JavaScript: cómo no exponer las contraseñas

La contraseña "qwerty123" ya no funciona: por qué la seguridad no es aburrida

Imagine: ha escrito una aplicación web genial. Interfaz bonita, código reactivo, todo vuela. La lanza, registra al primer usuario y, una hora después, su base de datos se filtra al dominio público. ¿Le suena esta historia? Lamentablemente, la autenticación segura en JavaScript es un tema que muchos desarrolladores posponen. Y es un error.

En este artículo, analizaremos cómo proteger su aplicación de los ataques más comunes: interceptación de tokens, XSS, CSRF y filtración de contraseñas. No daremos charlas sobre «hay que hacerlo bien»: mostraremos código que puede usar ahora mismo.

¿Listo? Allá vamos.

Autenticación en JavaScript: por qué el cliente es un campo de batalla

Cuando hablamos de autenticación en la web, a menudo pensamos en el backend: bases de datos, sesiones, hashes. Pero la autenticación en JavaScript comienza en el cliente. Y aquí nos acechan las trampas.

Todo lo que se ejecuta en el navegador puede ser leído, modificado o robado. Su código JavaScript es un libro abierto para un atacante si encuentra una vulnerabilidad. Por lo tanto, la primera regla de la autenticación segura es: nunca confíe en el cliente. Nunca.

Amenazas principales en el lado del cliente

• XSS (Cross-Site Scripting) — un atacante inyecta un script que roba tokens de localStorage.
• CSRF (Cross-Site Request Forgery) — el usuario está autenticado y un sitio malicioso envía solicitudes en su nombre.
• Man-in-the-Middle — interceptación del tráfico si no se usa HTTPS.
• Filtración de contraseñas — envío de la contraseña en texto plano o almacenamiento en el código.

¿Suena aterrador? En realidad, protegerse de esto no es tan difícil. Lo principal es saber qué herramientas usar.

JWT: conveniente, pero con trampa

JWT (JSON Web Token) es un estándar para crear tokens de acceso. Es ligero, no requiere almacenamiento en el servidor y es ideal para SPA. Pero su popularidad lo convierte en un objetivo.

Muchos desarrolladores almacenan JWT en localStorage. Esto es un error. localStorage es accesible desde cualquier código JavaScript en la página. Si tiene al menos una vulnerabilidad XSS, el token es robado.

Cómo almacenar JWT correctamente

La mejor manera es una cookie httpOnly. Las cookies con la bandera httpOnly no son accesibles desde JavaScript. XSS no las robará. Pero hay un detalle: las cookies se envían automáticamente con cada solicitud, lo que hace que la aplicación sea vulnerable a CSRF. La solución es usar SameSite y tokens CSRF.

Aquí hay un ejemplo de cómo configurar una cookie httpOnly en el backend (Node.js con Express):

// Servidor (Node.js / Express)res.cookie('token', jwtToken, {  httpOnly: true,       // No accesible desde JavaScript  secure: true,         // Solo por HTTPS  sameSite: 'strict',   // Protección contra CSRF  maxAge: 3600000       // 1 hora});

En el cliente, simplemente envía las solicitudes — las cookies se adjuntarán automáticamente:

// Cliente (JavaScript)fetch('/api/profile', {  method: 'GET',  credentials: 'include' // ¡Obligatorio!}).then(res => res.json()).then(data => console.log(data));

Tenga en cuenta: credentials: 'include' — sin esto, las cookies no se enviarán a otro origin.

Hash de contraseñas: bcrypt al rescate

Almacenar contraseñas en texto plano es como dejar las llaves de casa debajo del felpudo. Incluso si su sitio es hackeado, las contraseñas deben ser inútiles para el atacante.

bcrypt es un algoritmo de hash diseñado específicamente para ser lento. Porque hacer hash de una contraseña para el usuario lleva fracciones de segundo, pero para descifrarla, años. En JavaScript (Node.js), use la librería b