跳到正文

跨域、安全与浏览器存储 ​

  • 状态:未准备
  • 适用方向:前端 / Go 全栈
  • 最近复习:待填写
  • 下次复习:待安排

一句话回答 ​

同源策略约束不同源之间的访问,CORS 由服务端响应头授权浏览器读取;XSS 是注入执行,CSRF 是借用用户凭证发请求,存储和认证方案必须结合威胁模型选择。

原理解释 ​

跨域与 CORS ​

源由协议、主机、端口组成,路径不决定源。CORS 不是简单地禁止请求发出:部分跨域请求可以发送,但响应不允许脚本读取;需要预检时,浏览器先发送 OPTIONS,获准后才发实际请求。自定义头、application/json 等常触发预检。

带 Cookie 的跨域 fetch 通常需 credentials:'include',服务端明确允许对应 Origin 并设置允许凭证,不能用 Access-Control-Allow-Origin:*;Cookie 自身还受 SameSite 和浏览器策略约束。mode:'no-cors' 得到的 opaque 响应不能正常读取,不是修复 API 跨域的方案。

XSS 与 CSRF ​

XSS 可能来自不可信内容进入 HTML、脚本或 URL 上下文。优先安全的文本渲染,确需富文本时使用合适的净化方案,CSP 提供纵深防御。React 默认转义文本不代表 dangerouslySetInnerHTML 和危险链接都安全。

CSRF 利用浏览器随请求自动附带的凭证发起用户未授权的操作。可结合 CSRF token、Origin 校验、合适的 SameSite 和严格内容类型策略防护;不要用 GET 执行有副作用操作。CORS 不能替代 CSRF 防护。

存储比较 ​

方式主要特点边界
Cookie匹配条件时随请求发送,可设 HttpOnly / Secure / SameSiteHttpOnly 阻止脚本读取,不阻止 XSS 借当前身份发请求
localStorage同源、跨会话持久,字符串键值,同步 API脚本可读取,XSS 可窃取 token;可能受配额或策略限制
sessionStorage通常按源与顶层标签页会话隔离,同步 API刷新保留,关闭会话通常清除;不是机密存储
IndexedDB异步、结构化数据,适合较大离线数据需要处理版本升级、配额与清理,不能等同安全保险箱

场景与边界 ​

开发服务器代理让浏览器访问同源入口,由代理转发,不代表生产已解决跨域。跨站与跨源定义不同,SameSite 的 site 判断不能直接按 CORS 的 origin 判断替代。任何客户端权限检查都不能取代服务端鉴权。

项目中的应用 ​

结合 EinoTalk 登录态处理 解释 localStorage Bearer token 的便利与风险,并区分“当前已有行为”和可选的 HttpOnly Cookie 改造。

常见追问 ​

  • 前端设置响应头能解决 CORS 吗? 不能,授权由服务器或网关返回,浏览器执行检查。
  • HttpOnly 就不会有 XSS 问题吗? 不能,恶意脚本仍能访问页面数据和代用户操作。
  • 清空 token 就等于服务端注销吗? 不一定;服务端撤销、过期和会话控制要由具体认证方案保证。

参考资料 ​

理解机制,讲清取舍,用复盘检验掌握。