React认证处理：localStorage存储userId做鉴权是否存在安全漏洞？

你当前的处理方式存在明确的认证逻辑漏洞，不满足基础业务安全要求。核心问题不是“用户能获取他人公开数据”——这部分是你主动开放的合理业务逻辑，问题出在你把「可被用户随意篡改的明文userId」当成了登录态凭证，从认证逻辑的根上就站不住。

• 登录态校验完全失效：你用localStorage里存储的userId做免登依据、做路由登录拦截，这个值用户按F12打开控制台就能随意修改——随便填入其他用户的userId，你的前端就会直接把访问者识别成对应账号的已登录用户，连账号密码验证环节都直接跳过。如果后端接口也偷懒，直接读取请求参数里的userId识别请求者身份，就是典型的水平越权漏洞：用户改个参数就能冒充他人发评论、修改公开资料，你提到的“不返回邮箱、密码类隐私信息”根本做不了安全兜底，只要有一个接口漏做权限校验，就会出现隐私数据泄露、非授权操作的事故。
• localStorage的存储方式本身放大了攻击面：同域下运行的任意JS脚本都能读取localStorage的内容，万一后续项目引入的第三方依赖被投毒、或者页面出现XSS漏洞，攻击者写一行代码就能批量窃取所有访客的userId，冒充用户身份的成本极低。
• 权限边界模糊会留下长期隐患：把公开查询用的userId和登录身份识别绑定在一起，后续迭代接口的时候很容易出现逻辑疏漏，比如开发写接口时默认“传过来的userId就是当前登录用户”，不知不觉就把越权漏洞带到线上。

• 先把两类逻辑彻底拆分解耦：
  查询他人公开主页的接口，本身就允许传入任意合法userId返回非隐私公开数据，这部分逻辑不需要调整。但要记住：这类公开查询接口永远不能直接信任前端传的userId做身份判断，比如不能出现“请求参数里的userId和当前登录用户一致就返回隐私信息、允许修改操作”这类逻辑，当前登录用户的身份绝对不能从前端传的查询参数里获取。
• 替换裸userId的登录凭证方案：
  用户登录成功后，由服务端生成带签名、带过期时间、用户无法伪造的会话凭证（传统sessionId、服务端签名的JWT都可以，注意JWT不要存储敏感信息，签名密钥必须存在服务端）。优先把这个凭证存储在带HttpOnly、Secure、SameSite=Strict属性的Cookie中：前端JS无法读取HttpOnly Cookie的内容、用户无法手动篡改、XSS窃取的难度大幅提升，还能默认防御跨站请求伪造，是目前Web端登录态存储的最稳妥方案。
  如果因为架构原因确实不想用Cookie，非要把凭证存在前端存储中，优先选sessionStorage而非localStorage——关闭标签页就会自动清除内容，泄露风险更低。最核心的原则是：所有需要校验登录态的接口，服务端必须先验证会话凭证的合法性，从验证通过的凭证里解析出绑定的userId，绝对不能直接信任前端请求参数里传入的userId。
• 调整前端路由的登录校验逻辑：
  不要再靠读取localStorage里的userId判断用户是否登录，页面初始化时带着合法会话凭证请求服务端的当前用户信息接口（比如/api/user/current），服务端验证凭证有效就返回对应用户信息，验证失败就返回未登录状态，前端根据接口的实际返回结果判断是否放行路由、展示对应内容，不要在前端侧独立做登录态判定。

补充说明：允许用户访问他人公开主页、返回非隐私公开数据本身是完全合理的业务设计，不存在安全问题。你当前方案的核心错误是混淆了「公开查询参数」和「身份认证凭证」的边界——能证明“我是账号本人”的凭证，必须是用户无法伪造、无法篡改的，这是所有身份认证逻辑的基础底线。

内容的提问来源于stack exchange，提问作者Justin Seo