一个经典的面试题

“说说看。使用者登录后拿到的 Token，前端应该怎么存？”

这个问题看似简单，却能清晰地分辨出一个前端开发者对安全的理解深度。是存到 localStorage？sessionStorage？还是 Cookie？又或者是内存里，不同的选择背后是截然不同的安全考量。其实，

今天来聊一聊 Token 的存储之道。让你不仅知道怎么做，更明白为什么这么做。

选项一这方面，Web Storage

这是最直观、最容易想到的方案。其实，

// 登录成功后
const token = 'your_jwt_token_here';localStorage.setItem;怎么说呢，// 后续请求时带上
axios.interceptors.request.use => {
const token = localStorage.getItem;if {
config.headers.Authorization = `Bearer ${token}`;}
return config;
})，

优点：

• 容易上手API 简单，上手快。
• 永久存储（localStorage)：除非手动清除，否则一直存在。
• 会话期存储（sessionStorage)：页面关闭即清除，更安全一点。

致命缺点：

• 极易受到 XSS 的攻击. 如果网站存在 XSS 漏洞。攻击者的恶意脚本可以轻易地读取到 localStorage 中的所有 Token，从而窃取使用者身份。

不推荐，尤其对于敏感应用。

至于选项二，Cookie

Coo​kie 是传统且常见的身份验证载体。

// 服务端设置 Cookie
Set-Cookie: auth_token=your_jwt_token_here;
Path=/，HttpOnly;
Secure
// 前端无需特殊处理。浏览器会自动在每次请求中携带

注意这里的两个关键属性：

• HttpOnly: This is XSS antidote.. 设置了该属性后JavaScript 无法通过 alert) 等方式读取 Cookie，从而降低 XSS 风险。
• S​ecure: 强制 Cookie 只能在 HTTPS 协议下被发送，防止在网络传输中被窃听。

• 免疫 XSS: 无法通过 JS 读取，安全性高。不过，

是一个可行的方案。但必须配套完善的 CSRF 防御机制。