En la mayoría de las aplicaciones modernas de una sola página, tenemos que almacenar el token en algún lugar del lado del cliente (caso de uso más común: mantener al usuario conectado después de actualizar la página).

Hay un total de 2 opciones disponibles: almacenamiento web (almacenamiento de sesión, almacenamiento local) y una cookie del lado del cliente. Ambas opciones son muy utilizadas, pero esto no quiere decir que sean muy seguras.

Tom Abbott resume bien la seguridad de sessionStorage y localStorage de JWT :

Se puede acceder al almacenamiento web (localStorage/sessionStorage) a través de JavaScript en el mismo dominio. Esto significa que cualquier JavaScript que se ejecute en su sitio tendrá acceso al almacenamiento web y, debido a esto , puede ser vulnerable a los ataques de secuencias de comandos entre sitios (XSS) . XSS, en pocas palabras, es un tipo de vulnerabilidad donde un atacante puede inyectar JavaScript que se ejecutará en su página. Los ataques XSS básicos intentan inyectar JavaScript a través de entradas de formulario, donde el atacante coloca <script>alert('You are Hacked');</script> en un formulario para ver si el navegador lo ejecuta y otros usuarios pueden verlo. .

Para evitar XSS, la respuesta común es escapar y codificar todos los datos que no son de confianza. ¡React (principalmente) hace eso por ti! Aquí hay una gran discusión sobre la cantidad de protección de vulnerabilidad XSS de la que React es responsable .

¡Pero eso no cubre todas las posibles vulnerabilidades! Otra amenaza potencial es el uso de JavaScript alojado en CDN o en infraestructura externa .

Aquí está Tom de nuevo:

Las aplicaciones web modernas incluyen bibliotecas de JavaScript de terceros para pruebas A/B, análisis de embudo/mercado y anuncios. Usamos administradores de paquetes como Bower para importar el código de otras personas a nuestras aplicaciones.

¿Qué pasa si solo uno de los scripts que usa está comprometido? Se puede incrustar JavaScript malicioso en la página y el almacenamiento web se ve comprometido. Estos tipos de ataques XSS pueden obtener el almacenamiento web de todos los que visitan su sitio, sin su conocimiento. Esta es probablemente la razón por la que muchas organizaciones aconsejan no almacenar nada de valor ni confiar en ninguna información en el almacenamiento web. Esto incluye identificadores de sesión y tokens.

Por lo tanto, mi conclusión es que, como mecanismo de almacenamiento, el almacenamiento web no aplica ningún estándar seguro durante la transferencia . Quien lea el almacenamiento web y lo use debe hacer su debida diligencia para asegurarse de que siempre envíe el JWT a través de HTTPS y nunca HTTP.

Sé que esta es una vieja pregunta, pero de acuerdo con lo que dijo @ mikejones1477, las bibliotecas y los marcos modernos de front-end escapan del texto y le brindan protección contra XSS. La razón por la cual las cookies no son un método seguro que usa credenciales es que las cookies no evitan CSRF cuando lo hace localStorage (también recuerde que javascript también puede acceder a las cookies, por lo que XSS no es el gran problema aquí), esta respuesta resume por qué .

La razón por la que almacenar un token de autenticación en el almacenamiento local y agregarlo manualmente a cada solicitud protege contra CSRF es esa palabra clave: manual. Dado que el navegador no envía automáticamente ese token de autenticación, si visito evil.com y logra enviar un POST http://example.com/delete-my-account , no podrá enviar mi token de autenticación, por lo que la solicitud es ignorada.

Por supuesto, httpOnly es el santo grial, pero no puede acceder desde reactjs o cualquier marco js además de que aún tiene vulnerabilidad CSRF. Mi recomendación sería el almacenamiento local o si desea utilizar cookies, asegúrese de implementar alguna solución a su problema CSRF como lo hace Django .

Con respecto a los CDN, asegúrese de no estar usando algún CDN extraño, por ejemplo, CDN como google o bootstrap provide, son mantenidos por la comunidad y no contienen código malicioso, si no está seguro, puede revisarlo.

Básicamente, está bien almacenar su JWT en su almacenamiento local.

Y creo que esta es una buena manera. Si estamos hablando de XSS, XSS usando CDN, también es un riesgo potencial de obtener el inicio de sesión/contraseña de su cliente. El almacenamiento de datos en el almacenamiento local evitará al menos los ataques CSRF.

Tienes que ser consciente de ambos y elegir lo que quieras. Ambos ataques no son todo lo que debe tener en cuenta, solo recuerde: TODA SU APLICACIÓN SÓLO ES TAN SEGURA COMO EL PUNTO MENOS SEGURO DE SU APLICACIÓN.

Una vez más, almacenar está bien, ser vulnerable a XSS, CSRF,... no lo es