面试题手册

Cookie 是浏览器保存的一小段键值数据，通常用来让 HTTP 这种“无状态协议”记住用户状态。流程很简单：服务端在响应里用 Set-Cookie 下发 Cookie，浏览器按 Domain、Path、Expires、SameSite 等规则保存；之后访问匹配的地址时，浏览器会自动把 Cookie 放进 Cookie 请求头发回服务端。它常用于登录会话、用户偏好、购物车和统计分析。敏感会话 Cookie 一般要配 Secure、HttpOnly、SameSite，否则容易被窃取或被跨站请求滥用。追问Cookie 和 localStorage 有什么区别？Cookie 会随匹配请求自动发送给服务器，适合会话识别；localStorage 只在浏览器本地保存，不会自动进请求头，适合非敏感前端数据。Session Cookie 和持久 Cookie 有什么区别？不设置 Expires 或 Max-Age 的通常是会话 Cookie，浏览器会话结束后失效；设置了过期时间的是持久 Cookie。Cookie 为什么有安全风险？因为它可能代表登录态。被 XSS 读走会导致会话劫持，被 CSRF 利用会让浏览器自动带着 Cookie 发起恶意请求。SameSite、HttpOnly、Secure 分别解决什么问题？SameSite 缓解 CSRF，HttpOnly 防止脚本读取，Secure 限制只走 HTTPS。写段代码Set-Cookie: sessionId=abc; Path=/; Secure; HttpOnly; SameSite=LaxCookie: sessionId=abc

防止 Cookie 被窃取，核心是把“传输、读取、跨站发送、作用域”四件事管住：Secure 只允许 HTTPS 传输，降低中间人窃听风险；HttpOnly 禁止 JavaScript 读取，降低 XSS 偷 Cookie 的风险；SameSite 控制跨站请求是否带 Cookie，缓解 CSRF；Domain 和 Path 缩小发送范围。敏感登录态建议服务端设置 Cookie，不把 token 暴露给前端脚本，并优先使用 __Host- 前缀来避免子域覆盖。追问Secure 和 HttpOnly 有什么区别？Secure 管传输，只保证 Cookie 不走普通 HTTP；HttpOnly 管读取，防止 document.cookie 直接拿到敏感值。Path 能当安全边界吗？不能。Path 主要控制发送范围，不应把它当权限隔离。真正的权限判断必须在服务端做。为什么推荐 __Host- 前缀？它要求 Secure、Path=/，且不能设置 Domain，能避免子域种下同名 Cookie 覆盖主站会话。实战里如何排查 Cookie 被窃取？先看是否缺 HttpOnly 或 Secure，再查 XSS、第三方脚本、过宽 Domain，以及登录后 sessionId 是否轮换。写段代码Set-Cookie: __Host-token=abc; Secure; HttpOnly; SameSite=Strict; Path=/; Max-Age=1800

SameSite 是 Set-Cookie 的属性，用来决定 Cookie 是否会随跨站请求发送。它能缓解 CSRF，是因为 CSRF 依赖“用户已登录，浏览器自动带上目标站 Cookie”。当 Cookie 设置为 Strict 或多数情况下的 Lax 时，恶意站点发起的跨站 POST、iframe、图片等请求通常拿不到登录态。常规业务优先用 Lax；高敏感操作用 Strict；确实需要第三方嵌入或跨站登录时才用 None，并且必须同时加 Secure。追问Lax 会完全禁止跨站 Cookie 吗？不会。跨站顶级导航的安全方法，比如用户点击链接发起 GET，仍可能携带 Cookie，所以它更像折中方案。SameSite=None 为什么必须配 Secure？因为 None 允许跨站携带 Cookie，如果不用 HTTPS，Cookie 更容易在链路上泄露，现代浏览器也要求 None; Secure 组合使用。有 SameSite 还需要 CSRF Token 吗？高风险写操作仍建议保留 Token。SameSite 是浏览器策略，Token 是服务端校验，两者叠加更稳。项目里怎么选默认值？登录态默认 Lax；支付确认、改密码这类敏感 Cookie 用 Strict；第三方登录回调、嵌入式应用再评估 None; Secure。写段代码Set-Cookie: session=abc; Secure; HttpOnly; SameSite=Lax; Path=/Set-Cookie: iframe_token=xyz; Secure; HttpOnly; SameSite=None; Path=/

JavaScript 操作 Cookie 主要靠 document.cookie。读取时它返回当前页面可访问的 Cookie 字符串；设置时一次只能写入一个 name=value，不会清空其他 Cookie；删除本质是把同名 Cookie 的过期时间设为过去。实际开发要注意两点：值要用 encodeURIComponent 编码，删除时 Path、Domain 要和设置时一致，否则看起来执行了，其实没删掉。HttpOnly Cookie 不能被 JavaScript 读取或设置，只能由服务端通过 Set-Cookie 下发。追问document.cookie = xxx 会覆盖所有 Cookie 吗？不会。它只会新增或更新当前这一个 Cookie。读取 document.cookie 才会看到多个 Cookie 拼成的字符串。为什么删除 Cookie 有时不生效？大概率是 Path 或 Domain 不一致。比如设置时用了 Path=/app，删除时只写 Path=/，浏览器会认为它们不是同一个 Cookie。为什么要编码 Cookie 值？Cookie 值里如果有空格、分号、中文等特殊字符，可能导致解析错误。写入用 encodeURIComponent，读取用 decodeURIComponent。JavaScript 能设置 HttpOnly 吗？不能。HttpOnly 的目的就是禁止脚本访问 Cookie，必须由服务端设置。写段代码function setCookie(name, value, maxAge, path = '/') { document.cookie = `${name}=${encodeURIComponent(value)}; Max-Age=${maxAge}; Path=${path}`;}function getCookie(name) { return document.cookie.split('; ').find(v => v.startsWith(name + '=')) ?.split('=').slice(1).join('=') || null;}function deleteCookie(name, path = '/') { document.cookie = `${name}=; Max-Age=0; Path=${path}`;}

Cookie 的主要风险有四类：XSS 读取 document.cookie、CSRF 借浏览器自动带 Cookie 发请求、HTTP 明文传输被中间人截获，以及 Domain/Path 配置过宽导致 Cookie 被子域或无关路径滥用。敏感 Cookie 应由服务端设置，并组合使用 HttpOnly、Secure、SameSite=Lax/Strict、短有效期和签名校验。注意：SameSite 能降低 CSRF 风险，但高风险写操作仍建议校验 CSRF Token 或 Origin/Referer。追问HttpOnly 能彻底防住 XSS 吗？不能。它只是禁止 JavaScript 读取 Cookie，不能阻止脚本执行，也不能阻止恶意脚本发起带 Cookie 的请求。SameSite=Lax 和 Strict 怎么选？普通登录态多用 Lax，兼顾外部链接跳转体验；支付、后台管理等高风险场景可用 Strict。Cookie 被篡改怎么办？不要信任客户端值。服务端应对 Cookie 做签名或只存 sessionId，真实权限状态放服务端。实际项目里最容易漏什么？SameSite=None 忘记配 Secure，浏览器会拒绝或异常处理；另一个坑是把主站 session 设置到 .example.com，导致子域风险放大。写段代码Set-Cookie: __Host-session=abc; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=3600

Cookie 浏览器兼容差异主要集中在容量限制、SameSite 默认值、第三方 Cookie、隐私保护策略和过期时间。现在不能再假设“所有浏览器都会长期保存并发送 Cookie”：Safari 的 ITP、Firefox 的 ETP、Chrome 的第三方 Cookie 收紧都会影响跨站登录、埋点和广告归因。处理思路是默认一方 Cookie、SameSite=Lax、Secure 开启，跨站场景单独设计降级方案。追问各浏览器容量差异要怎么记？单个 Cookie 通常按 4KB 估算，每个域名数量上限各家不同。面试里不必背精确数字，关键是不要依赖“能存很多”，超过少量会话字段就该换存储方案。SameSite=None 为什么必须配 Secure？因为 SameSite=None 表示允许跨站发送 Cookie，风险更高。现代浏览器要求它只能在 HTTPS 下配合 Secure 使用，否则可能直接拒收。Safari ITP 对业务影响最大在哪里？跨站追踪、第三方登录态和长期归因最容易出问题。即使代码没变，Cookie 也可能被限制有效期或阻止发送，所以要用真实 Safari 和隐私模式测试。第三方 Cookie 被禁后怎么办？优先改成一方登录态；确实跨域时，用 OAuth 跳转、服务端会话、postMessage 或浏览器提供的新 API，而不是继续依赖隐藏 iframe 写 Cookie。写段代码document.cookie = 'sid=abc; Path=/; Secure; SameSite=Lax';// 跨站且必须携带时：document.cookie = 'sso=abc; Path=/; Secure; SameSite=None';

Cookie 的 Domain 决定哪些域名会收到它，Path 决定哪些路径会收到它。默认不写 Domain 时，Cookie 通常只属于当前 host；写成父域如 example.com 时，子域也可能共享。Path 是路径前缀匹配，不是权限隔离，主要用于减少无关请求携带 Cookie。正确做法是按最小范围设置，登录态、后台、支付、静态资源不要混用一个宽泛 Cookie。追问不写 Domain 和写 Domain 有什么区别？不写 Domain 更收敛，通常只给当前主机使用。写父域会扩大到子域，适合 SSO，但也扩大了泄露和冲突范围。现在前导点 .example.com 基本被忽略，关键是域本身是否合法。Path=/api 能防止前端 JS 读取 Cookie 吗？不能。Path 控制请求是否携带 Cookie，不是安全边界。要防 JS 读取，应设置 HttpOnly；要跨站防护，还要配合 SameSite 和 CSRF 方案。Path 的匹配规则是什么？它是前缀匹配。Path=/admin 会匹配 /admin 和 /admin/user，但设计时最好写清楚边界，避免 /admin-old 这类路径造成误判。实际项目怎么设置？会话 Cookie 尽量只给需要鉴权的域和路径；静态资源放到无 Cookie 域名；管理后台、支付、开放 API 分开命名和作用域，排查时也更清楚。写段代码Set-Cookie: sid=abc; Domain=example.com; Path=/; HttpOnly; Secure; SameSite=LaxSet-Cookie: admin=xyz; Path=/admin; HttpOnly; Secure; SameSite=Strict

Cookie 性能优化的核心是少带、少存、少匹配。因为同域请求会自动携带匹配 Cookie，Cookie 越多，请求头越大，移动网络和高并发接口越容易被拖慢。实战里优先把会话凭证保留在 Cookie，把偏好、缓存、草稿这类非敏感数据迁到 localStorage、sessionStorage 或 IndexedDB；同时收窄 Domain、Path，避免静态资源和无关接口也背着 Cookie 跑。追问Cookie 为什么会影响接口性能？每次 HTTP 请求都会带上匹配的 Cookie。即使只是请求一张图片，只要域名和路径匹配，也可能多传几 KB 请求头。HTTP/2 有 HPACK 压缩，但不能把设计不当的 Cookie 变成零成本。减少 Cookie 大小有哪些做法？只存必要字段，键名和值都尽量短；多个小偏好可以合并成一个值，但不要把大对象硬塞进去。超过 4KB 或频繁变化的数据不适合放 Cookie。Domain 和 Path 怎么配合性能优化？Domain 不要随手设成 .example.com，Path 也不要一律 /。例如后台令牌只给 admin.example.com 和 /admin，API Cookie 只给 /api，静态资源域名最好不设置 Cookie。项目里常见坑是什么？分析、AB 实验、灰度标记容易越积越多，最后每个请求都多带一串历史垃圾。上线前可以在网关或浏览器 DevTools 里看 Request Headers，超过 2KB 就该清理。写段代码function cookieBytes() { return new Blob([document.cookie]).size;}if (cookieBytes() > 2048) { console.warn('Cookie too large:', cookieBytes());}

iframe 跨域通信用 window.postMessage：父页拿到 iframe 的 contentWindow 发消息，子页用 window.parent.postMessage 回消息，双方用 message 事件接收。安全重点只有两句：发送时别乱用 *，接收时必须校验 event.origin 和 event.data，否则任何页面都可能伪造消息触发你的逻辑。追问postMessage 为什么能跨域？它是浏览器提供的受控跨文档通信 API，不直接暴露 DOM，只传递结构化克隆后的数据，所以绕开的是直接访问限制，不是绕开安全校验。targetOrigin 能不能写 *？只有广播类、完全不含敏感信息的消息才考虑 *。登录态、token、订单状态、支付结果都必须写明确源，例如 https://pay.example.com。接收消息时要校验什么？先校验 event.origin，再校验数据结构和 type 白名单。不要把 event.data 直接拼进 HTML，也不要让消息直接驱动跳转、支付、删除等高危操作。transfer 参数有什么用？它可以转移 MessagePort、ArrayBuffer 等对象所有权，适合大数据或双向通道。普通业务状态同步通常用不到。写段代码iframe.contentWindow.postMessage({ type: 'init' }, 'https://child.example');window.addEventListener('message', (event) => { if (event.origin !== 'https://child.example') return; if (!event.data || event.data.type !== 'resize') return; iframe.style.height = `${Number(event.data.height) || 0}px`;});

iframe 的 sandbox 是给嵌入页面加一层浏览器级限制：默认禁止脚本、表单、弹窗、顶层跳转，并把内容放进独立的特殊源。安全配置的原则是先空 sandbox，再按功能逐项放开；最危险的组合是同源页面同时给 allow-scripts 和 allow-same-origin，子页面可能移除 sandbox 或访问同源能力。追问空 sandbox 和不写 sandbox 有什么区别？空 sandbox 是最严格模式；不写 sandbox 等于 iframe 按普通页面运行。第三方、不可信 HTML、广告位优先用空 sandbox。常用权限怎么选？只展示内容：sandbox；需要 JS：allow-scripts；需要提交表单：加 allow-forms；需要弹窗：加 allow-popups；需要跳转父页面，优先用 allow-top-navigation-by-user-activation，别直接用 allow-top-navigation。为什么 allow-scripts + allow-same-origin 危险？如果 iframe 和父页同源，脚本恢复后可能读写同源资源，甚至移除自身 sandbox。可信内部页可以用，不可信内容不要这么配。实际项目里还要配什么？配合 CSP 的 frame-src 限制可嵌入来源，并定期审查权限。sandbox 是能力限制，CSP 是来源限制，两者解决的问题不一样。写段代码<iframe src="https://third.example" sandbox></iframe><iframe src="https://widget.example" sandbox="allow-scripts allow-forms"></iframe>