flawopen.com/CSRF/GET 请求
GET 请求何时需要 CSRF 令牌？
参考页面
简要结论
如果 GET 只读取数据，就不应改变服务器状态，通常也不需要 CSRF 令牌。浏览器、爬虫、预览和嵌入资源可能在没有用户主动点击时发起 GET。因此，删除或购买等操作应使用不安全方法，并保护基于 cookie 认证的状态变更请求免受 CSRF。旧的状态变更型 GET 仍然有漏洞，迁移期间需要临时防护。
为什么 GET 必须保持安全语义
RFC 9110 将 GET 定义为安全方法：客户端不会请求改变状态。安全并不表示服务器没有日志记录等附带效果。GET 也是幂等的，但两者是不同属性。浏览器、预取、爬虫和链接预览可能在没有用户明确操作时发出安全请求。其他网站中的 <img src="..."> 也可能让浏览器携带用户 cookie 发送 GET。如果接口借此删除内容或更改账户设置，就违反了 GET 语义，普通页面内容也可能触发该操作。
在改变状态的请求上实施 CSRF 防护
- ✓GET、HEAD 和 OPTIONS 不应执行请求的状态变更；变更操作使用 POST、PUT、PATCH 或 DELETE
- ✓对基于 cookie 认证的不安全方法使用框架的 CSRF 防护或验证令牌；再叠加 SameSite 和 Origin/Fetch Metadata 检查
- ✓将任何状态变更型 GET 视为 HTTP 方法语义错误；必要时临时增加 CSRF 防护，随后迁移操作并从 URL 中移除秘密
GET 请求的 CSRF 常见问题
旧代码有状态变更型 GET 接口怎么办？
将其视为有漏洞。临时要求服务器验证 CSRF 防护（例如 synchronizer token，并在支持时检查 Origin 或 Fetch Metadata），审查缓存和 Referer，然后迁移到 POST、PUT、PATCH 或 DELETE。避免把令牌放在查询字符串中：URL 可能出现在浏览器历史、日志和 Referer 数据中。令牌检查只是迁移期间的过渡措施，最终接口应遵循安全方法语义。