O JWT deve ser armazenado em localStorage ou cookie? [duplicado]

Com o propósito de proteger a API REST usando JWT, de acordo com alguns materiais (como este guia e esta pergunta ), o JWT pode ser armazenado em localStorage ou Cookies . Com base no meu entendimento:

• localStorage está sujeito a XSS e geralmente não é recomendado armazenar nenhuma informação sensível nele.
• Com os Cookies , podemos aplicar o sinalizador "httpOnly" que atenua o risco de XSS. No entanto, se quisermos ler o JWT de Cookies no backend, estaremos sujeitos ao CSRF.

Portanto, com base na premissa acima, será melhor armazenarmos JWT em Cookies. Em cada solicitação ao servidor, o JWT será lido dos cookies e adicionado no cabeçalho de autorização usando o esquema do portador. O servidor pode então verificar o JWT no cabeçalho da solicitação (em vez de lê-lo dos cookies).

Meu entendimento está correto? Em caso afirmativo, a abordagem acima tem alguma preocupação com a segurança? Ou, na verdade, podemos simplesmente usar o localStorage em primeiro lugar?

Eu gosto do método XSRF Double Submit Cookies mencionado no artigo que @ pkid169 disse, mas há uma coisa que esse artigo não diz a você. Você ainda não está protegido contra XSS porque o que o invasor pode fazer é injetar um script que lê seu cookie CSRF (que não é HttpOnly) e, em seguida, fazer uma solicitação para um de seus endpoints de API usando este token CSRF com o cookie JWT sendo enviado automaticamente.

Portanto, na realidade, você ainda é suscetível a XSS, mas o invasor não pode roubar seu token JWT para uso posterior, mas ainda pode fazer solicitações em nome de seus usuários usando XSS.

Quer você armazene seu JWT em um localStorage ou armazene seu token XSRF em um cookie não apenas http, ambos podem ser capturados facilmente pelo XSS. Até mesmo seu JWT no cookie HttpOnly pode ser capturado por um ataque XSS avançado.

Portanto, além do método Double Submit Cookies, você deve sempre seguir as melhores práticas contra XSS, incluindo conteúdo de escape. Isso significa remover qualquer código executável que faria com que o navegador fizesse algo que você não deseja. Normalmente, isso significa remover // <! [CDATA [tags e atributos HTML que fazem com que o JavaScript seja avaliado.

Uma postagem oportuna de Stormpath elaborou bastante meus pontos e respondeu à minha pergunta.

TL; DR

Armazene o JWT em cookies e, em seguida, passe o JWT no cabeçalho de autorização em cada solicitação, como mencionei, ou, como o artigo sugere, conte com o back-end para evitar CSRF (por exemplo, usando xsrfTokenno caso de Angular).

• Não armazene seu token em LocalStorage ou SessionStorage, porque tal token pode ser lido em javascript e, portanto, é vulnerável a ataques XSS.
• Não armazene seu token no Cookie. Cookie (com sinalizador HttpOnly) é uma opção melhor - é propenso a XSS, mas é vulnerável a ataques CSRF

Em vez disso, no login, você pode entregar dois tokens: token de acesso e token de atualização. O token de acesso deve ser armazenado na memória Javascript e o token de atualização deve ser armazenado no cookie HttpOnly. O token de atualização é usado apenas e apenas para criar novos tokens de acesso - nada mais.

Quando o usuário abre uma nova aba, ou na atualização do site, você precisa realizar a solicitação para criar um novo token de acesso, baseado no token de atualização que está armazenado no Cookie.

Também recomendo fortemente a leitura deste artigo: https://hasura.io/blog/best-practices-of-using-jwt-with-graphql/

Para ajudar a prevenir ataques CSRF que tiram vantagem de cookies existentes, você pode definir seu cookie com a SameSitediretiva. Defina-o como laxou strict.

Este ainda é um rascunho e em 2019 não é totalmente compatível com todos os navegadores atuais , mas dependendo da sensibilidade de seus dados e / ou seu controle sobre os navegadores que seus usuários usam, pode ser uma opção viável. Definir a diretiva com SameSite=laxpermitirá "navegações de nível superior que usam um método HTTP 'seguro' ...".