Quiero traer una duda sobre los tokens JWT y CSRF delPoste de tormenta que explican las ventajas y desventajas de almacenar el JWT en localStorage o cookies.

[...] si está leyendo valores de una cookie utilizando JS, eso significa que no puede establecer el indicador Httponly en la cookie, por lo que ahora cualquier JS en su sitio puede leerlo, por lo que es exactamente la misma seguridad: nivel como almacenar algo en localStorage.

Estoy tratando de entender por qué recomiendan agregar xsrfToken al JWT. ¿El almacenamiento de su JWT en la cookie y luego extraerlo y colocar el JWT en el encabezado HTTP y autenticar la solicitud basada en el encabezado HTTP logran lo mismo que X-XSRF-TOKEN de Angular? Ningún otro dominio podría realizar solicitudes en nombre de un usuario si se autentica en función del JWT en el encabezado, ya que otros dominios no pueden extraer el JWT de la cookie. No entiendo el propósito del xsrfToken en el JWT, quizás sea solo una capa adicional de defensa, lo que significa que los atacantes tendrían que tener un script comprometido en su sitio y CSRF un usuario en ese momento. Entonces tendrían que golpearte de ambas maneras para poder atacar.

La publicación está vinculada enesta respuesta donde dice:

Lo último es asegurarse de tener protección CSRF en cada solicitud HTTP para garantizar que los dominios externos que inician solicitudes a su sitio no puedan funcionar.

[...] Luego, en cada solicitud en su servidor, asegúrese de que su propio código JavaScript lea el valor de la cookie y lo establezca en un encabezado personalizado, p. X-CSRF-Token y verifique ese valor en cada solicitud en el servidor.Los clientes de dominio externo no pueden establecer encabezados personalizados para las solicitudes a su dominio a menos que el cliente externo obtenga autorización a través de una solicitud de Opciones HTTP, por lo que cualquier intento de un ataque CSRF (por ejemplo, en un IFrame, lo que sea) fallará para ellos.

Incluso si pudieran establecer encabezados personalizados, no podrían acceder a la cookie donde se almacena el token JWT porque solo JavaScript que se ejecuta en el mismo dominio puede leer la cookie.

La única forma en que podrían hacerlo es a través de XSS, pero tener un xsrfToken en el JWT también se ve comprometido si existen vulnerabilidades de XSS porque un script malicioso que se ejecuta en el dominio del cliente de confianza podría acceder al JWT en la cookie e incluir un encabezado en la solicitud con el xsrfToken .

Entonces la ecuación debería ser:

TLS + JWT almacenado en cookie segura + JWT en encabezado de solicitud + Sin vulnerabilidades XSS.

Si el cliente y el servidor se ejecutan en diferentes dominios, el servidor debe enviar el JWT y el cliente debe crear la cookie con el JWT. Creo que la ecuación sigue siendo válida para esta situación.

ACTUALIZAR: MvdD de acuerdo conmigo:

Como el navegador no agrega automáticamente el encabezado a su solicitud, no es vulnerable a un ataque CSRF