Cookie、Session 与跨域
信息技术大学
Cookie、Session 与跨域
计算机基础面试八股 · 第 1 章 计算机网络
按 空格/→ 演示下一步
全部页面点击任意一页，跳回舞台从这页播放
信息技术大学
Cookie、Session 与跨域
计算机基础面试八股 · 第 1 章 计算机网络
Cookie 属性与安全位
Cookie 是浏览器替站点保管的小纸条，属性决定它的作用域、寿命与暴露面。
作用域
Domain + Path 决定哪些请求会带上它
寿命
会话 Cookie 关浏览器即失效；Expires/MaxAge 定长命
安全位
HttpOnly 禁 JS 读、Secure 仅 HTTPS 发、SameSite 管跨站
Session 服务端会话机制
状态存在服务端，客户端只拿一张号码牌——Session 是经典的有状态登录方案。
号码牌
登录后生成 SessionID，经 Set-Cookie 下发
服务端存储
内存、Redis 或数据库，按 SessionID 查会话
集群难题
多机不共享状态，粘性会话或集中存储二选一
生命周期
空闲超时与主动注销都要清理服务端记录
健身房手环对应 →Session
档案在前台柜里（服务端），手环号只是查询凭证
JWT 结构与无状态认证
JWT 把会话数据签名后直接交给客户端保管，服务端不存状态，验签即可信任。
三段式
Header.Payload.Signature，前两段 Base64URL 编码
签名防篡改
服务端密钥对前两段签名，改一个字就验不过
无状态
不查库即可认证，天然适合分布式与跨服务
代价
签发后难撤销，只能靠短有效期 + 刷新令牌缓解
拆开一个 JWT
javascript
前两段只是编码不是加密，别把敏感信息塞进 Payload。
代码高亮加载中…
Payload 明文可解码阅读，签名只保证不被篡改——短有效期 exp 是盗用风险的兜底。
同源策略与 CORS
浏览器把不同源的资源隔开：协议、域名、端口任一不同即跨域，CORS 是官方放行通道。
同源定义
协议、域名、端口三者完全一致才算同源
CORS 机制
服务端回 Access-Control-Allow-* 头显式放行
预检请求
非简单请求先发 OPTIONS 探路，通过才发真实请求
带凭据
跨站携带 Cookie 时源不能是通配符，须精确指定
一次 CORS 预检的往返
浏览器替用户先把关：服务器点头，真实请求才出发。
1
预检 OPTIONS
带 Origin、方法与自定义首部询问服务器
2
服务端应答
回 Allow-Origin 等头，声明允许的源与方法
3
真实请求
预检通过，浏览器才发出真正的业务请求
4
失败拦截
服务器不放行，响应被浏览器拦下并报错
本节要点
- ✓Cookie 存客户端，Session 存服务端
- ✓安全三件套：HttpOnly、Secure、SameSite
- ✓JWT 无状态好扩展，但签发后难撤销
- ✓跨域是浏览器行为，CORS 由服务端放行
延伸主题：用 DevTools 看 Set-Cookie手动造一次跨域被拦
课后思考
先自己回答，再展开参考答案——能讲出来才算真懂。
1HttpOnly 已能防 XSS 偷 Cookie，为什么还需要 SameSite？
参考答案HttpOnly 只挡页面脚本读取，挡不住浏览器自动携带 Cookie 发出的跨站请求；SameSite 从发送侧掐断 CSRF 通道，两者防线互补。
2Session 集群部署时，为什么常改用 Redis 集中存储？
参考答案会话存在本机内存时，负载均衡把请求分到另一台就丢失登录态；要么粘性会话绑定机器，要么把会话搬到所有节点都能查的 Redis。
3JWT 已签发却要「立即踢人下线」，有什么可行做法？
参考答案JWT 无状态导致无法直接作废：常用短有效期加刷新令牌控制窗口，或在服务端维护黑名单、用户版本号，把无状态折衷回可控。