「明明保持着登录，只是打开了『另一个站点』，转账或修改设置就在你不知情时被执行了」——这就是 CSRF。本文讲解其原理以及可靠的防范方法（不会写出攻击步骤）。
为什么能成立（原理）
浏览器在向某个站点发起请求时，会自动附带该站点的 Cookie。因此，只要用户正登录着银行站点，即便是从另一个恶意页面向银行发出操作请求，浏览器也会把「本人的 Cookie」一并发出去。从服务器看来，这与本人的正规操作毫无区别。
XSS 是「让代码在受害者的浏览器中运行」，而 CSRF 是「擅自借用受害者的登录状态」的攻击（→ XSS 是什么）。
防御
强制要求 CSRF Token
对改变状态的操作（表单提交、API）要求一个无法猜测的一次性 Token。由服务器签发，请求中若不包含它则拒绝。许多框架都内置提供。
设置 SameSite Cookie
给会话 Cookie 加上 SameSite=Lax（或 Strict），不让源自其他站点的请求附带 Cookie。近年的默认值是 Lax，仅此一项就能起到很大作用。
不用 GET 来改变状态
设计上让浏览（GET）不产生副作用。变更一律用 POST/PUT/DELETE，并通过 Token 校验。
校验 Origin / Referer
对重要操作，在服务器端确认请求来源（Origin）是否为本站，拒绝外部来源。
本站观点：几乎已「解决」但仍不可大意
凭借现代框架的 CSRF Token＋浏览器的 SameSite=Lax 默认值，典型的 CSRF 已大幅减少。话虽如此，在自行实现的 API、老旧结构、省去了 Token 的管理后台中，至今仍然照样能被命中。即使「全权交给框架」，也最好亲自确认一次改变状态的路径上是否都通过了 Token 校验，这样更安全。
常见的漏洞缝隙
即便了解原理，在实现中也容易在以下两点出现疏漏。
- 让 GET 带有副作用：如果设计成用于浏览的 GET 会改变状态，那么仅凭一个图片标签或一条普通链接就可能让 CSRF 成立。改变状态务必使用 POST/PUT/DELETE，并通过 Token 校验。
- 只有部分路径忘了做 Token 校验：在后来追加的 API 或管理功能中，常常会漏掉 Token 校验。不要因「已交给框架」就放心，请把所有改变状态的路径清点一遍。
接着阅读
FAQ
QCSRF 和 XSS 有什么区别？
XSS 是让「脚本在受害者的浏览器中执行」的攻击，CSRF 则是「借用受害者的登录状态发出并非本意的请求」的攻击。CSRF 即使无法执行脚本，仅凭 Cookie 会被自动发送这一特性就能成立。
QCSRF 最主要的防御是什么？
对改变状态的操作（POST 等）强制要求 CSRF Token，并给会话 Cookie 设置 SameSite（Lax/Strict）。许多框架都内置提供 Token。此外，不用 GET 来改变状态也是基本原则。
Q只靠 SameSite Cookie 够吗？
效果很大，但并非万能。在旧版浏览器、某些跳转、子域名结构等情况下仍可能留有缝隙，因此与 CSRF Token 并用的多层防御才更安全。