Quero colocar uma dúvida sobre os tokens JWT e o CSRF doPost Stormpath que explicam as vantagens e desvantagens de armazenar o JWT no localStorage ou nos cookies.

[...] se você está lendo valores de um cookie usando JS, significa que não pode definir o sinalizador Httponly no cookie, então agora qualquer JS em seu site pode lê-lo, tornando-o exatamente a mesma segurança- nível como armazenar algo no localStorage.

Estou tentando entender por que eles recomendam adicionar o xsrfToken ao JWT. O armazenamento da sua JWT no cookie e a extração e colocação da JWT no cabeçalho HTTP e a autenticação da solicitação com base no cabeçalho HTTP realizam o mesmo que o X-XSRF-TOKEN da Angular? Nenhum outro domínio poderá fazer solicitações em nome de um usuário se você se autenticar com base no JWT no cabeçalho, pois outros domínios não poderão extrair o JWT do cookie. Não entendo o objetivo do xsrfToken no JWT - talvez seja apenas uma camada adicional de defesa - o que significa que os invasores precisam ter um script comprometido em seu site e CSRF como usuário no momento. Então eles teriam que acertar em você de ambas as formas para poder atacar.

A postagem está vinculada emesta resposta onde diz:

A última coisa é garantir que você tenha proteção CSRF em todas as solicitações HTTP para garantir que os domínios externos que iniciam solicitações ao seu site não possam funcionar.

[...] Em todas as solicitações do servidor, verifique se o seu próprio código JavaScript lê o valor do cookie e o define em um cabeçalho personalizado, por exemplo. X-CSRF-Token e verifique esse valor em todas as solicitações no servidor.Clientes de domínio externo não podem definir cabeçalhos personalizados para solicitações ao seu domínio, a menos que o cliente externo obtenha autorização por meio de uma solicitação de Opções HTTP, portanto, qualquer tentativa de ataque ao CSRF (por exemplo, em um IFrame, qualquer que seja) falhará.

Mesmo se eles pudessem definir cabeçalhos personalizados, não poderiam acessar o cookie em que o token JWT está armazenado, porque apenas o JavaScript executado no mesmo domínio pode ler o cookie.

A única maneira possível: via XSS, mas ter um xsrfToken no JWT também é comprometido se existirem vulnerabilidades XSS, porque um script mal-intencionado em execução no domínio do cliente confiável pode acessar o JWT no cookie e incluir um cabeçalho na solicitação com o xsrfToken .

Portanto, a equação deve ser:

TLS + JWT armazenado no cookie seguro + JWT no cabeçalho da solicitação + Nenhuma vulnerabilidade XSS.

Se o cliente e o servidor estiverem em execução em domínios diferentes, o servidor deverá enviar o JWT e o cliente deverá criar o cookie com o JWT. Eu acho que a equação ainda é válida para esta situação.

ATUALIZAR: MvdD concorda comigo:

Como o navegador não adiciona automaticamente o cabeçalho à sua solicitação, ele não é vulnerável a um ataque CSRF