CSRF（跨站请求伪造）

为什么浏览器的 Cookie 机制造成了这个问题

浏览器有一个核心行为：向任何域发送请求时，都会自动附带该域的 Cookie，无论请求发起自哪个页面。因此，当攻击者的页面里有一个隐藏的 ，受害者的浏览器在加载该图片时会自动带上 bank.com 的 Session Cookie，银行服务器看到的是一个来自已认证用户的合法转账请求。

2007 年，ING Direct 银行被研究员演示 CSRF 漏洞，可在用户不知情下完成账户转账。同年，YouTub 被发现存在 CSRF 漏洞，可代替用户添加视频到播放列表、发送消息。Netflix 直到 2008 年才修复允许攻击者修改账户设置的 CSRF 漏洞。[1]

防御：Token、SameSite 与双提交

CSRF Token 是经典防御：服务端在表单或 API 响应中包含一个随机且与 Session 绑定的 Token，每次请求时提交该 Token，服务端验证。跨域请求无法读取目标域页面的 DOM（同源策略限制），因此无法获取 Token。

SameSite Cookie 属性（Chrome 80 于 2020 年 2 月起将默认值改为 Lax）从根源上解决问题：Strict 模式下 Cookie 只在同站请求中附带，跨站请求不带 Cookie，CSRF 失效。Lax 允许顶层导航携带 Cookie，对绝大多数 CSRF 场景也足够防护。SameSite=None 需同时加 Secure（仅 HTTPS）。

现代 API 常用 双重提交 Cookie（Double Submit Cookie）：Token 同时存在 Cookie 和请求参数中，服务端验证两者是否一致，不依赖 Session 存储，适合无状态 API。