我知道这是一个老问题，但根据@mikejones1477所说，现代前端库和框架转义文本，为您提供对XSS的保护。cookie不是使用凭证的安全方法的原因是，当localStorage阻止CSRF时，cookie不能阻止CSRF(还要记住，cookie也可以通过JavaScript访问，所以XSS不是这里的大问题)，这就是为什么的答案。

在本地存储中存储身份验证令牌并手动将其添加到每个请求中以防止CSRF的原因是关键字:手动。由于浏览器不会自动发送认证令牌，如果我访问邪恶。例如，它设法发送一个POST http://example.com/delete-my-account，它将无法发送我的authn令牌，因此该请求被忽略。

当然httpOnly是圣杯，但你不能从reactjs或任何js框架访问，你仍然有CSRF漏洞。我的建议是localstorage，或者如果你想使用cookie，确保像Django一样实现一些解决CSRF问题的解决方案。

关于CDN，确保你没有使用一些奇怪的CDN，例如谷歌或bootstrap提供的CDN，由社区维护，不包含恶意代码，如果你不确定，你可以自由审查。

localStorage和httpOnly cookie都不能接受吗?关于一个妥协的第三方库，我所知道的唯一能减少/防止敏感信息被窃取的解决方案是强制执行子资源完整性。

子资源完整性(SRI)是一种安全特性 浏览器验证它们获取的资源(例如从CDN) 交付时没有意外的操作。它通过允许 您可以提供所获取资源必须的加密散列 匹配。

只要受感染的第三方库在您的网站上是活跃的，键盘记录程序就可以开始收集信息，如用户名，密码，以及您输入到网站的任何其他内容。

httpOnly cookie将阻止来自另一台计算机的访问，但不会阻止黑客操纵用户的计算机。

如果你使用CDN是不安全的:

恶意JavaScript可以嵌入到页面中，Web存储就会受到威胁。这些类型的XSS攻击可以在不知情的情况下获取访问您站点的每个人的Web存储。这可能就是为什么许多组织建议不要在网络存储中存储任何有价值的东西或信任任何信息的原因。这包括会话标识符和令牌。 通过stormpath

您从外部需要的任何脚本都可能被破坏，并可能从客户机的存储中获取任何JWTS，并将个人数据发送回攻击者的服务器。

我对所有建议不要存储在本地存储的答案感到不安，因为这很容易受到XSS攻击或恶意库的攻击。其中一些问题甚至会进入冗长的讨论，尽管答案非常小/简单，我很快就会讲到。

这就相当于说:“不要用煎锅做饭，因为如果你某天晚上喝醉了，决定用煎锅做饭，你会把自己和房子都烤焦的。” 如果jwt由于XSS攻击或恶意库而泄露，那么站点所有者就有更大的问题:他们的站点容易受到XSS攻击或正在使用恶意库。

答案是:如果你确信你的网站不存在这些漏洞，那就去做吧。

裁判:https://auth0.com/docs/security/data-security/token-storage # browser-local-storage-scenarios

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

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

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

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

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

总共有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。