前端安全与网络面试 25 问：XSS、CSRF、CORS、HTTPS 与鉴权

安全和网络是前端面试里最容易被低估、也最容易失分的一块。原因是它横跨浏览器、协议、服务端三个层面，很多人只记得几个名词缩写，一追问”那具体怎么防”就答不上来。

本文按同源策略 → XSS → CSRF → CORS → HTTPS → 鉴权 → 传输协议七段组织，每段给出可直接口述的答案框架。这部分内容稳定，不随框架版本变动，性价比很高。

一、同源策略：所有安全问题的起点

Q1：什么是同源？同源限制了什么？

同源 = 协议 + 域名 + 端口 三者完全相同。注意端口是参与比较的，example.com 和 example.com:8080 不同源。

同源策略限制三类行为：

1. DOM 访问：不同源的 iframe 之间不能互相读 DOM（contentWindow.document 会抛错）。
2. 数据读取：不能读取不同源下的 Cookie、LocalStorage、IndexedDB。
3. 网络响应：XMLHttpRequest/fetch 发出的跨域请求，响应会被浏览器拦截（请求实际已发出、服务端也收到了，只是拿不到结果）。

高频追问：”跨域请求到底有没有发到服务器？”——发了。简单请求会完整发出并被服务端处理，只是响应被浏览器扣下；非简单请求会先发 OPTIONS 预检，预检不通过才不会发真实请求。这个区别在排查”服务端日志里有请求但前端报错”时很关键。

Q2：有哪些合法的跨域方案？

• CORS：服务端在响应头里声明允许的源，标准方案。
• 反向代理：开发环境的标配（Vite server.proxy、Nginx）。本质是让浏览器以为同源。
• JSONP：利用 <script> 不受同源限制，只支持 GET、已淘汰，知道原理即可。
• postMessage：iframe / 弹窗之间跨域通信的标准 API。
• WebSocket：本身不受同源策略限制（但服务端应校验 Origin）。

二、XSS：把别人的脚本执行在你的页面上

Q3：XSS 分哪几类？

类型	注入路径	是否经过服务端	典型场景
存储型	恶意内容存进数据库	是	评论、昵称、富文本
反射型	恶意内容在 URL 参数里	是（原样返回）	搜索页回显、错误页
DOM 型	前端 JS 直接把不可信数据写进 DOM	否	innerHTML = location.hash

Q4：怎么防？说出三层防线

第一层：输出编码 / 转义。这是最根本的。把用户数据当成”文本”而不是”HTML”插入：

// 危险：把字符串当作 HTML 解析
el.innerHTML = userInput
document.write(userInput)

// 安全：作为纯文本插入
el.textContent = userInput

// Vue / React 的插值默认就是安全的
<div>{{ userInput }}</div>        // 会转义
<div v-html="userInput"></div>   // 危险，等同于 innerHTML
<div dangerouslySetInnerHTML={{__html: x}} />  // React 中的危险写法

第二层：CSP（内容安全策略）。通过响应头限定页面能加载和执行的资源来源，即使发生了注入，脚本也跑不起来：

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://cdn.example.com;
  object-src 'none';
  base-uri 'self';
  frame-ancestors 'none'

要点：避免用 unsafe-inline 和 unsafe-eval，否则 CSP 形同虚设。实际落地时先上 Content-Security-Policy-Report-Only 观察一段时间再切正式。

第三层：富文本白名单。业务上确实需要渲染 HTML 时（比如文章正文），必须用 DOMPurify 这类库做白名单清洗，不要自己写正则过滤——正则做 HTML 过滤几乎一定会被绕过。

三、CSRF：借你的身份发请求

Q5：CSRF 的原理是什么？和 XSS 有什么区别？

核心区别一句话：XSS 是”在你的页面里执行我的脚本”，CSRF 是”借你的 Cookie 发我不想发的请求”。

• XSS 利用了你对用户的信任（用户信任这个网站）。
• CSRF 利用了网站对用户浏览器的信任（服务端看到 Cookie 就认为是本人）。

攻击流程：用户登录了银行站点 A，Cookie 还在；然后访问了恶意站点 B，B 的页面里有一个自动提交的表单或 <img src="https://a.com/transfer?to=evil&amount=1000">；浏览器发请求时会自动带上 A 的 Cookie，于是转账成功。

Q6：CSRF 怎么防？

1. SameSite Cookie（首选，最省事）：给 Cookie 加 SameSite=Lax（或 Strict），浏览器就不会在跨站请求里自动带上它。
2. CSRF Token：服务端下发一个随机 token 埋在页面里，请求时带上，服务端校验。攻击者拿不到这个 token，因为它在别的域下读不到你的页面内容。
3. 校验 Origin / Referer：服务端检查请求来源是否在白名单内。作为辅助手段，别单独依赖（Referer 可能被隐私策略剥离）。
4. 关键操作二次确认：短信验证码、密码确认、人机验证。

Set-Cookie: session=xxx; HttpOnly; Secure; SameSite=Lax; Path=/

面试高频追问：”用了 Token 存 LocalStorage 是不是就没有 CSRF 问题了？“——是的，CSRF 的前提是浏览器自动携带凭证，手动在 Authorization 头里塞 token 不会自动带上，因此天然免疫 CSRF。但代价是它暴露给了 JS，XSS 一打就全没了。这是两个风险之间的取舍，不是白拿。

四、CORS：把跨域说清楚

Q7：简单请求和预检请求的区别？

同时满足以下条件的才是简单请求（不触发预检）：

• 方法是 GET、HEAD、POST 之一
• 请求头只包含 Accept、Accept-Language、Content-Language、Content-Type（且值仅为 application/x-www-form-urlencoded、multipart/form-data、text/plain）、Range

所以 Content-Type: application/json 会触发预检——这是实际开发中最常见的”为什么多了个 OPTIONS 请求”的原因。

Q8：带 Cookie 的跨域请求要注意什么？

// 前端
fetch('https://api.example.com/data', {
  credentials: 'include'    // axios 对应 withCredentials: true
})

// 服务端响应头
Access-Control-Allow-Origin: https://app.example.com   // 不能是 *
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Max-Age: 86400        // 预检结果缓存 24h，减少 OPTIONS

三个必考点：① Allow-Origin 不能是通配符 *；② 必须带 Allow-Credentials: true；③ 配合 SameSite=None 时，Cookie 必须同时带 Secure，也就是必须走 HTTPS。

五、HTTPS 与传输安全

Q9：HTTPS 握手过程能讲一遍吗？

抓住主线，不用背到每个字节：

1. 客户端发 ClientHello：支持的 TLS 版本、密码套件列表、随机数。
2. 服务端回 ServerHello：选定的套件、随机数、数字证书。
3. 客户端校验证书：是否由可信 CA 签发、域名是否匹配、是否在有效期内、是否被吊销（OCSP / CRL）。
4. 密钥交换：TLS 1.3 下用 ECDHE 交换临时密钥，双方算出相同的会话密钥。因为临时密钥不参与长期存储，所以具备前向安全性。
5. 切换到对称加密（如 AES-GCM）传输应用数据。

加分点：TLS 1.3 把握手从 2-RTT 压缩到 1-RTT，会话复用时是 0-RTT，并且砍掉了一批不安全的套件（静态 RSA 密钥交换、RC4、SHA-1 等）。

Q10：中间人攻击是怎么防住的？

靠证书链 + 签名验证而不是加密本身。中间人确实可以拦下流量、伪造一个证书，但他拿不到受信任 CA 的私钥，签不出能通过浏览器校验的证书。浏览器内置了根 CA 列表，逐级验证签名，任何一级对不上就拦下来。

这也是为什么公司抓包工具需要你手动安装并信任它的根证书——一旦你信任了，它就能签出合法证书，HTTPS 的防护就被你主动绕过了。

Q11：Cookie 的四个安全属性分别管什么？

• Secure：只在 HTTPS 下发送。
• HttpOnly：禁止 JS 读取（document.cookie 拿不到），是防 XSS 窃取会话的关键。
• SameSite：Strict 完全禁止跨站携带；Lax 允许导航类 GET 请求携带（当前主流默认值）；None 允许跨站携带（需配合 Secure）。
• __Host- 前缀：强制该 Cookie 必须 Secure、Path=/、不带 Domain，防止子域覆盖。

六、鉴权方案怎么选

Q12：Session-Cookie 和 JWT 各自的取舍？

维度	Session + Cookie	JWT
状态存储	服务端存（Redis 等）	无状态，服务端不存
扩展性	需要共享存储 / 粘性会话	天然适合多节点
主动失效	容易，删掉 session 即可	难，签发后无法单方面收回
载荷大小	只有一个 sessionId	每次请求都带上完整载荷
适合的场景	需要即时踢人、权限变更频繁	短时效、跨域调用、一次性令牌

关键判断句：JWT 的”无状态”既是优点也是代价——它换来的扩展性，是以”无法主动失效”为代价的。实践中常用的折中是短时效 Access Token + 可刷新的 Refresh Token，并在服务端维护一份轻量的黑名单来兜底。

Q13：JWT 存在哪里？

• localStorage：方便，但 XSS 可直接读取。不推荐放长期凭证。
• Cookie（HttpOnly + Secure + SameSite）：JS 读不到，XSS 拿不走，但需要防 CSRF。生产环境更稳的选择。
• 内存（变量 / 状态管理）：最安全，刷新即失效，配合 Refresh Token 使用。

高分答法：没有银弹，只有取舍。Cookie 方案怕 CSRF（可用 SameSite 缓解），localStorage 方案怕 XSS（无解，只能靠 CSP 和输出编码去降低 XSS 发生的概率）。所以问题的落点是”你更怕哪一个，以及你的 XSS 防线有多厚“。

七、HTTP 版本与传输

Q14：HTTP/1.1、2、3 的核心差异？

• HTTP/1.1：文本协议，长连接，但存在队头阻塞（同一连接上请求必须排队）。浏览器靠开 6 个连接缓解。
• HTTP/2：二进制分帧 + 多路复用，一个连接上并发多个流，解决了应用层的队头阻塞；附带 HPACK 头部压缩、服务端推送（实践中效果不佳，已基本弃用）。
• HTTP/3：传输层从 TCP 换成 QUIC（基于 UDP），解决了 TCP 层的队头阻塞——丢包时不再阻塞所有流；握手合并进 TLS，连接建立更快；支持连接迁移（切换网络不断线）。

追问”那 HTTP/2 还有队头阻塞吗”——有。它只在应用层解决了，TCP 层丢包时，所有流仍然要等重传。这就是为什么需要 HTTP/3。

Q15：强缓存和协商缓存怎么配合？

// 强缓存：命中则完全不发请求
Cache-Control: max-age=31536000, immutable    // 带 hash 的静态资源
Cache-Control: no-cache                        // 允许缓存但每次必须校验

// 协商缓存：发请求问服务端，没变则返回 304
Etag: "abc123"           // 请求时带 If-None-Match
Last-Modified:     // 请求时带 If-Modified-Since

标准策略：带内容 hash 的静态资源用 max-age=1年, immutable；HTML 入口用 no-cache。这样发版时 HTML 会重新校验，一旦内容变了就引用新的 hash 文件名，旧资源自然失效。

八、小结

这一块的答题方法论是先分层、再讲权衡：同源策略是地基，XSS 是”脚本注入”、CSRF 是”凭证盗用”，两者靶子不同；CORS 是同源策略的授权出口而不是安全边界；HTTPS 靠的是证书信任链；鉴权方案的核心权衡在”状态放哪”和”能否主动失效”。

能把这五句讲清楚，并且每个防护手段都说得出”它防的是什么、代价是什么”，这一块基本稳了。

---

参考：MDN · CSP、MDN · CORS、OWASP Top 10。安全建议随标准演进，落地前请以官方最新文档为准。