看待这个问题的一种方法是考虑风险或伤害的水平。

你是否正在创造一款没有用户的应用，即POC/MVP?你是一家需要快速进入市场并测试应用程序的初创公司吗?如果是，我可能只会实施最简单的解决方案，并继续专注于寻找适合市场的产品。使用localStorage，因为它通常更容易实现。

你是在开发一款拥有大量日活跃用户的应用的v2版本，还是一款人们/企业非常依赖的应用?被黑客攻击是否意味着几乎没有恢复空间?如果是这样，我会仔细研究一下您的依赖关系，并考虑将令牌信息存储在仅http的cookie中。

使用localStorage和cookie/session存储都有各自的优缺点。

正如第一个答案所述:如果您的应用程序有XSS漏洞，那么两者都不能保护您的用户。由于大多数现代应用程序都有十几个或更多不同的依赖项，因此越来越难以保证应用程序的某个依赖项不受XSS攻击。

如果您的应用程序确实存在XSS漏洞，并且黑客已经能够利用它，那么黑客将能够代表您的用户执行操作。黑客可以通过从localStorage检索令牌来执行GET/POST请求，或者如果令牌存储在http-only cookie中，则可以执行POST请求。

在本地存储中存储令牌的唯一缺点是黑客将能够读取您的令牌。

基本上可以将JWT存储在localStorage中。

我认为这是一个好方法。 如果我们谈论的是XSS, XSS使用CDN，这也是一个潜在的风险，获得您客户的登录/通行证。将数据存储在本地至少可以防止CSRF攻击。

你需要了解这两点，然后选择你想要的。这两种攻击都不是你所需要注意的，只要记住:你的整个应用程序的安全性仅与你的应用程序的最不安全的点一样。

再次重申，存储是OK的，易受XSS, CSRF，…不是

Localstorage被设计成可以通过javascript访问，所以它不提供任何XSS保护。正如在其他回答中提到的，有很多可能的方式来进行XSS攻击，默认情况下，本地存储不受保护。

However, cookies have security flags which protect from XSS and CSRF attacks. HttpOnly flag prevents client side javascript from accessing the cookie, Secure flag only allows the browser to transfer the cookie through ssl, and SameSite flag ensures that the cookie is sent only to the origin. Although I just checked and SameSite is currently supported only in Opera and Chrome, so to protect from CSRF it's better to use other strategies. For example, sending an encrypted token in another cookie with some public user data.

因此，cookie是存储身份验证数据的更安全的选择。

TLDR;

两者都可以工作，但是使用httpOnly cookie要比使用localStorage安全得多，因为XSS引入的任何恶意javascript代码都可以读取localStorage。

只要加密，将令牌存储在localStorage中是安全的。下面是一个压缩的代码片段，展示了许多方法中的一种。

    import SimpleCrypto from 'simple-crypto-js';

    const saveToken = (token = '') => {
          const encryptInit = new SimpleCrypto('PRIVATE_KEY_STORED_IN_ENV_FILE');
          const encryptedToken = encryptInit.encrypt(token);

          localStorage.setItem('token', encryptedToken);
     }

然后，在使用令牌之前，使用PRIVATE_KEY_STORED_IN_ENV_FILE对其进行解密

在大多数现代单页应用程序中，我们确实必须将令牌存储在客户端某处(最常见的用例——在页面刷新后保持用户登录)。

总共有2个选项可用:Web Storage(会话存储，本地存储)和客户端cookie。这两种方法都被广泛使用，但这并不意味着它们非常安全。

Tom Abbott很好地总结了JWT sessionStorage和localStorage安全性:

Web Storage (localStorage/sessionStorage) is accessible through JavaScript on the same domain. This means that any JavaScript running on your site will have access to web storage, and because of this can be vulnerable to cross-site scripting (XSS) attacks. XSS, in a nutshell, is a type of vulnerability where an attacker can inject JavaScript that will run on your page. Basic XSS attacks attempt to inject JavaScript through form inputs, where the attacker puts <script>alert('You are Hacked');</script> into a form to see if it is run by the browser and can be viewed by other users.

为了防止XSS，常见的响应是转义和编码所有不可信的数据。React(主要)为您做这些!这里有一个关于React在多大程度上负责XSS漏洞保护的很好的讨论。

但这并没有涵盖所有可能的漏洞!另一个潜在威胁是JavaScript托管在cdn或外部基础设施上的使用。

汤姆说:

Modern web apps include 3rd party JavaScript libraries for A/B testing, funnel/market analysis, and ads. We use package managers like Bower to import other peoples’ code into our apps. What if only one of the scripts you use is compromised? Malicious JavaScript can be embedded on the page, and Web Storage is compromised. These types of XSS attacks can get everyone’s Web Storage that visits your site, without their knowledge. This is probably why a bunch of organizations advise not to store anything of value or trust any information in web storage. This includes session identifiers and tokens.

因此，我的结论是，作为一种存储机制，Web storage在传输过程中没有强制执行任何安全标准。任何阅读Web Storage并使用它的人都必须尽职尽责，以确保始终通过HTTPS而不是HTTP发送JWT。