Los JWT son simples de producir, y en parte por eso se implementan mal con frecuencia. Estos son los errores que causan vulnerabilidades reales.
1. Confiar en la cabecera alg
La cabecera indica qué algoritmo se usó. Si el servidor lee el algoritmo del token y lo obedece, un atacante puede poner alg en none o pasar de un algoritmo asimétrico a uno simétrico. El servidor debe fijar los algoritmos permitidos en su propia configuración y rechazar cualquier otro.
2. Secretos débiles o adivinables
Un secreto HS256 como secret o password puede romperse sin conexión por fuerza bruta, porque cualquiera con un token puede probar suposiciones. Usa un valor aleatorio largo generado por una fuente segura y guárdalo fuera del código.
3. No verificar la firma
Decodificar no es verificar. Ejecuta siempre la función de verificación de la biblioteca, no solo una decodificación, antes de confiar en cualquier afirmación.
4. Ignorar la caducidad y la audiencia
Comprueba exp y, cuando corresponda, nbf, iss y aud. Mantén los tokens de acceso de vida corta, minutos y no días, y usa tokens de refresco con cuidado.
5. Poner datos sensibles en la carga útil
La carga útil la puede leer cualquiera que tenga el token. Limítala a identificadores y permisos, nunca a secretos personales.
6. Almacenamiento inseguro
Los tokens en localStorage pueden ser leídos por cualquier script de la página si hay un fallo de cross-site scripting. Las cookies con las marcas HttpOnly, Secure y SameSite suelen ser más seguras frente al robo por scripts, aunque necesitan protección contra CSRF.
7. Sin forma de revocar
Un JWT válido sigue siendo válido hasta que caduca. Planifica la revocación con vidas cortas, una lista de denegación o tokens de refresco rotatorios.
Usar herramientas de prueba con seguridad
Los codificadores y decodificadores son estupendos para aprender y depurar. Usa en ellos secretos falsos y datos de ejemplo, y no pegues nunca tokens o claves reales de producción en una página de terceros.
Preguntas frecuentes
¿Los JWT son una mala idea? Están bien para el uso adecuado, pero las sesiones de servidor normales son más simples para muchos sitios.
¿Puedo poner un JWT en una URL? Evítalo, ya que las URL acaban en registros y en el historial del navegador.