前端存 Access Token 到底该用 localStorage 还是 cookie？

UP主～文阁提问于 2026-03-16 19:31:18 阅读 45

安全

最近在做登录功能，后端返回了 Access Token，但我不确定该存在哪。听说 localStorage 容易被 XSS 攻击，但用 cookie 又怕 CSRF，到底怎么选才安全？

我试过把 token 存 localStorage，像这样：localStorage.setItem('token', res.token)，但同事说这不安全。如果改用 cookie，是不是得加 HttpOnly 和 SameSite？可那样前端又读不到 token 了，咋办？

认证授权

我来解答赞 12 收藏

反馈

2 条解答

长孙含平 Lv1

按照规范，前端存储 Access Token 的时候，推荐使用 cookie 而不是 localStorage。localStorage 确实容易受到 XSS 攻击，而 cookie 的安全性可以通过设置一些标志来增强。

对于 CSRF 风险，你需要在 cookie 中设置 HttpOnly 标志来防止 JavaScript 访问 cookie，同时设置 SameSite=Strict 或 SameSite=Lax 来防止 CSRF 攻击。不过，设置了 HttpOnly 后，前端就无法通过 JavaScript 读取这个 cookie 了，这在某些情况下可能是个问题。

一个常见的做法是使用双重提交模式来解决 CSRF 问题。具体来说，服务器生成一个 CSRF token，并将其作为 cookie 和表单字段发送给客户端。当客户端提交请求时，服务器会验证这两个 token 是否一致，从而确保请求的合法性。

至于如何在前端获取 Access Token，通常的做法是让后端在需要验证用户身份的接口中，通过验证 cookie 来决定是否允许请求，而不是直接将 token 发送到前端。这样可以避免前端直接暴露 token 的风险。

举个例子，如果你的 API 需要认证，你可以这样设置 cookie：

document.cookie = "accessToken=" + res.token + "; HttpOnly; SameSite=Strict; path=/";

然后在每次发起请求时，浏览器会自动将这个 cookie 发送到服务器，无需手动附加 token。

希望这些信息对你有帮助。

2026-03-24 16:01

雪利 ☘︎ Lv1

这个问题挺经典的，说白了就是 XSS 和 CSRF 两个风险的权衡。

localStorage 确实有 XSS 风险，因为任何能执行你页面 JS 的漏洞都能直接读走 token。但说实话，cookie 方案搞对了比 localStorage 安全得多。

核心在于：token 存 cookie 的话，设成 HttpOnly + SameSite，浏览器会自动帮你发送，根本不需要前端去读。CSRF 的问题不是 cookie 的锅，是你后端没有做 CSRF 防护。

推荐的做法是这样的：

后端设置两个 cookie，一个是 token（HttpOnly + SameSite=Strict），另一个是 CSRF token（不用 HttpOnly，前端要读）。登录时后端同时返回这两个东西，前端把 CSRF token 存 localStorage 或者内存里，每次发请求时：

// 请求头里带上 CSRF token

fetch('/api/protected', {

  method: 'POST',

  headers: {

    'Content-Type': 'application/json',

    'X-CSRF-Token': localStorage.getItem('csrfToken')

  },

  credentials: 'include'  // 这个很重要，会自动带 cookie

})

后端验证两点：cookie 里的 token 是不是有效的，以及请求头里的 CSRF token 是不是匹配。这样 XSS 读不走 token（HttpOnly 挡着），CSRF 也攻击不了（没有匹配的 CSRF token）。

如果你们后端不想改，那简单方案就是 localStorage + 每次请求用 Authorization 头：

// 存 localStorage

localStorage.setItem('accessToken', res.token);



// 请求时放 header

fetch('/api/xxx', {

  headers: {

    'Authorization': 'Bearer ' + localStorage.getItem('accessToken')

  }

})

这种方式CSRF 风险确实存在，因为浏览器会自动带 cookie，但至少 token 本身不会被 XSS 直接偷走。要完全安全还是得用第一种方案。

总的来说，业务敏感度高的话，别省那点功夫，老老实实做 cookie + CSRF token 这套。

2026-03-17 09:09