问题描述
我正在制作一个 ReactJS 应用程序，并且有一个基于令牌的身份验证 (Laravel Sanctum)，它在用户登录时发出，我保存在浏览器的本地存储中。因此，我可以查找令牌并在像 Postman 这样的 HTTP 客户端中使用它。
让我担心的另一件事是我将会员信息存储在本地存储中，例如：
{
name: "John Doe",privileges: [1,2,3,4],jobPositionID: 1,departmentID: 5
}
它们不是敏感信息（令牌除外），但我是构建 SPA 的新手，并且我对这一切的安全方面感到安全。
解决方法
在大多数现代单页面应用程序中，我们确实必须将令牌存储在客户端的某个地方（最常见的用例 - 以保持用户在页面刷新后登录）。
共有 2 个选项可用：Web 存储（会话存储、本地存储）和客户端 cookie。这两个选项都被广泛使用，但这并不意味着它们非常安全。
Tom Abbott 很好地总结了 JWT sessionStorage 和 localStorage 安全性：
Web Storage (localStorage/sessionStorage) 可以通过 同一域上的 JavaScript。这意味着任何运行的 JavaScript 在您的网站上将可以访问网络存储，因此可以 容易受到跨站点脚本 (XSS) 攻击。 XSS，在一个 简而言之，是一种攻击者可以注入的漏洞 将在您的页面上运行的 JavaScript。基本的 XSS 攻击试图 通过表单输入注入 JavaScript，攻击者在其中放置
alert('你被黑了');成一个表格，看看是不是由浏览器运行，其他用户可以查看。
为了防止 XSS，常见的反应是对所有不受信任的数据进行转义和编码。 React（大部分）为你做这件事！这里有一个关于 React 负责多少 XSS 漏洞保护的精彩讨论。
但这并没有涵盖所有可能的漏洞！另一个潜在威胁是使用托管在 CDN 或外部基础架构上的 JavaScript。
汤姆又来了：
现代网络应用包括用于 A/B 的 3rd 方 JavaScript 库 测试、漏斗/市场分析和广告。我们使用包管理器，如 Bower 将其他人的代码导入到我们的应用中。
如果您使用的脚本中只有一个遭到破坏怎么办？恶意 JavaScript 可以嵌入页面，Web Storage 是 妥协了。这些类型的 XSS 攻击可以获取每个人的 Web Storage 在他们不知情的情况下访问您的网站。这可能是为什么一个 一堆组织建议不要存储任何有价值或信任的东西 网络存储中的任何信息。这包括会话标识符和 令牌。
因此，我的结论是，作为一种存储机制，Web Storage 在传输过程中不会强制执行任何安全标准。阅读并使用 Web Storage 的任何人都必须尽职尽责，以确保他们始终通过 HTTPS 而不是 HTTP 发送 JWT。
https://newbedev.com/is-it-safe-to-store-a-jwt-in-localstorage-with-reactjs