Te recomendamos que pruebes esta respuesta en un entorno controlado antes de enviarlo a producción, un saludo.
Solución:
En la mayoría de las aplicaciones modernas de una sola página, de hecho 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 una actualización de 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 se utilizan ampliamente, pero esto no significa 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 ataques de secuencias de comandos entre sitios (XSS). XSS, en pocas palabras, es un tipo de vulnerabilidad en la que un atacante puede inyectar JavaScript que se ejecutará en su página. Los ataques básicos XSS intentan inyectar JavaScript a través de entradas de formulario, donde el atacante coloca
en un formulario para ver si lo ejecuta el navegador 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 cuánto es responsable la protección contra vulnerabilidades XSS de React.
¡Pero eso no cubre todas las posibles vulnerabilidades! Otra amenaza potencial es el uso de JavaScript alojado en CDN o infraestructura externa.
Aquí está Tom de nuevo:
Las aplicaciones web modernas incluyen bibliotecas de JavaScript de terceros para pruebas A / B, análisis de mercado / embudo 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. Probablemente esta sea la razón por la que un grupo de organizaciones aconseja no almacenar nada de valor ni confiar en ninguna información en el almacenamiento web. Esto incluye identificadores de sesión y tokens.
Por tanto, mi conclusión es que, como mecanismo de almacenamiento, Web Storage no aplica ningún estándar seguro durante la transferencia. Quien lea Web Storage y lo utilice debe hacer su debida diligencia para asegurarse de que siempre envía el JWT a través de HTTPS y nunca de HTTP.
Sé que esta es una pregunta antigua, pero de acuerdo con lo que dijo @ mikejones1477, las bibliotecas y los marcos frontales modernos escapan al texto y le brindan protección contra XSS. La razón por la que las cookies no son un método seguro que usa credenciales es que las cookies no evitan CSRF cuando localStorage lo hace (también recuerde que las cookies también son accesibles mediante javascript, 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 que key palabra: 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 se ignora.
Por supuesto, httpOnly es el santo grial, pero no puede acceder desde reactjs o cualquier marco js a su lado, todavía 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 de CSRF como lo hace django.
Con respecto a los CDN, asegúrese de no estar usando un 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 localStorage.
Y creo que esta es una buena forma. Si estamos hablando de XSS, XSS usando CDN, también existe un riesgo potencial de obtener el nombre de usuario / contraseña de su cliente. El almacenamiento de datos en el almacenamiento local evitará al menos los ataques CSRF.
Debes ser consciente de ambos y elegir lo que quieres. Ambos ataques no es todo lo que debes tener en cuenta, solo recuerda: TODA TU APLICACIÓN ES SOLO TAN SEGURA COMO EL PUNTO MENOS SEGURO DE TU APLICACIÓN.
Una vez más, el almacenamiento está bien, ser vulnerable a XSS, CSRF, …
Aquí puedes ver las comentarios y valoraciones de los lectores
Eres capaz de añadir valor a nuestra información colaborando tu experiencia en las referencias.