别再往localStorage里塞token了，这些坑你踩过几个

误区一：localStorage存token，方便就完事了

这是前端圈子里流传最广的偷懒写法。新手教程里经常这么教——登录成功后拿到token，顺手localStorage.setItem存起来，下次请求带上就行。看起来没毛病，实际上埋了一颗定时炸弹。

不少已经上线跑了一两年的项目，至今还在用这种方式管理登录态。开发者觉得又不是银行系统没那么严格，但现实是：只要你的页面存在一个XSS漏洞，攻击者一行document.cookie都不用碰，直接读localStorage就能把token拿走。

误区二：我做了输入校验，XSS不会发生在我这里

很多团队的安全意识停留在输入框做了过滤就行。但XSS的攻击面远不止表单输入。第三方脚本、富文本编辑器、URL参数拼接、甚至CDN被污染，都可能成为注入点。

更麻烦的是，现代前端项目依赖大量npm包，供应链攻击已经不是新闻了。某个深层依赖被植入恶意代码，打包后混在你的业务JS里，运行时悄悄把localStorage里的内容发到外部服务器——这种事不是假设，是真实发生过的安全事件。

为什么这些做法是错的

根本原因在于：localStorage对JavaScript完全开放。任何在当前域下执行的JS代码，不管是你自己写的还是被注入的，都能无条件读写localStorage的全部内容。它没有访问控制，没有过期机制，没有加密，就是一个对脚本透明的键值仓库。

换句话说，localStorage的设计初衷就不是用来存敏感信息的。它适合存主题偏好、语言设置这类丢了也无所谓的数据。把身份凭证放进去，相当于把家门钥匙挂在门把手上——门锁本身可能很结实，但钥匙谁都能拿。

而sessionStorage虽然生命周期短一些，关闭标签页就清除，但在XSS面前同样毫无抵抗力，本质问题一模一样。

正确做法：httpOnly Cookie方案

把token的存储和传输交给httpOnly Cookie。具体操作是：后端在登录接口的响应头里通过Set-Cookie下发token，同时设置httpOnly、Secure、SameSite属性。

httpOnly的作用很直接——禁止JavaScript读取这个cookie。就算页面被XSS了，攻击者的脚本也拿不到cookie内容。Secure确保只在HTTPS下传输，SameSite限制跨站请求携带，三者组合起来构成基本防线。

前端这边不需要手动管理token了。浏览器会自动在同域请求里带上cookie，接口该怎么调还怎么调。如果是跨域场景，配合credentials include和后端的CORS白名单即可。

补充：短期token加refresh机制

access_token设置较短过期时间（比如15分钟），refresh_token放在httpOnly cookie里，过期后静默刷新。这样即使access_token意外泄露，窗口期也非常有限。

上线前自查清单

以下几项逐条过一遍，没做到的赶紧补：

1. localStorage和sessionStorage里是否还残留token、密码、用户敏感信息？全部清理掉。

2. 身份凭证是否已迁移到httpOnly Cookie？确认Set-Cookie响应头包含httpOnly、Secure、SameSite=Strict或Lax。

3. 前端是否存在innerHTML直接拼接用户输入的写法？逐一排查并替换为textContent或经过转义处理。

4. 第三方脚本是否使用了integrity属性做子资源完整性校验？没有的话加上SRI hash。

5. CSP头是否已配置？至少限制script-src为白名单域，杜绝inline脚本执行。

6. 定期跑一次依赖审计（npm audit），看看有没有已知漏洞的包还在项目里。

安全这件事没有一劳永逸的方案，但至少别在最基础的地方翻车。把token从localStorage挪出来，是成本最低、收益最明确的一步。