我正在构建一个对GUI和React进行响应的node.js Web应用程序，该GUI和与Apollo一起使用的graphQL用于后端连接到AWS上的RDS（MySQL）实例。
我正在验证用户身份，然后返回JWT。我已经找到了如何更新/过期令牌的方法，但是现在我面临的问题是，当用户访问该站点时，将其保存在客户端的位置...
有两个主要概念，第三个是混合模型。 1）如HowToGraphQL所述，将其存储为带有JavaScript的localStorage 2）将其存储在Cookie中，并且仅将http-设置为true，如上述文章中描述为阳离子reference to Randall Degges
还有另一种选择，仅将其存储在客户端的内存中，但是每次刷新页面时，用户都必须登录，因为它在任何地方都不会持久。
概念1仅在已经利用了另一个XSS漏洞的情况下才容易受到XSS的攻击。但是它仅对站点安全，因此只有在站点上运行的脚本可以访问它，而不能在任何站点上的脚本访问。关于安全性的说法很多，即使它是通用的方式也不应以这种方式存储，因为开发人员无法信任他们在其站点上运行的每个JavaScript脚本，并且可能会有一个读取localStorage的代码然后将其发送到异地。
概念2通过声明仅http使其仅可被您站点的服务器访问，从而消除了XSS的漏洞。这里的问题在于，然后必须创建一个单独的方法，以将相同的后端身份验证用于其他用途，例如标准API（用于本机应用程序或其他站点），其中JWT通过其存储在https上的标头中发送安全地在另一台服务器上。
因此，我进行了研究，发现此hybrid method described by Ben Awad 3）使用了请求令牌和刷新令牌。然后，请求令牌可以正常使用标准API，然后在我们的React App网站上，我们可以将其仅存储在内存中，并将刷新令牌存储在Cookie中，以便在用户刷新或关闭并重新打开浏览器时发回请求令牌。] >
因此，从理论上讲，最好的解决方案是概念3，它解决了所有问题，但是设置起来当然更复杂。
我的问题：我应该为JWT开放XSS漏洞感到担忧吗？当我有更多时间时，这是我要走的很长的路要走，但我正在争取最后期限。我的网站将鲜为人知，并且不会像黑客那样必然会针对的是Facebook或Sales-force。我的网站除了基本的CRM和任务列表以外，没有存储信用卡数据或其他高度敏感的数据。如果我的站点通过其他代码对XSS开放，那么即使在不了解JWT的情况下，整个身份验证过程也不会因键盘记录脚本等漏洞而受到攻击。我觉得我会做很多额外的工作来保护可能的威胁，如果发生这种威胁，整个系统将已经受到威胁。
我正在构建一个具有GUI响应的node.js Web应用程序，并为Apollo提供了与Apollo一起使用的graphQL，用于后端连接到AWS上的RDS（MySQL）实例。我正在认证用户，然后...