在请求头中发送Anti-CSRF token是否是良好的安全实践？

该方案的防护有效性 #

请求头携带Anti-CSRF Token是CSRF防护场景下有效性非常高的方案，核心优势如下：

• 同源策略默认限制第三方站点无法读取跨域请求的响应内容，也不允许第三方页面自定义请求头发起跨域请求（除非目标服务端主动配置CORS放开相关权限），攻击者既无法获取用户当前会话下的有效CSRF Token，也无法将合法Token塞入自定义请求头伪造请求
• 相比放在表单参数、URL参数中的Token存储方案，请求头存储不会出现URL泄露、服务端日志记录泄露Token的问题，也不会被表单自动提交的特性绕过防护
• 只要Token本身满足不可预测、和用户会话强绑定、会话过期后自动失效的生成规则，可以覆盖绝大多数常规CSRF攻击场景

该方案不是全场景最优安全方案 #

没有任何单一安全方案能应对所有类型的Web攻击，该方案也存在明确的局限性：

• 仅能防御CSRF攻击，对XSS、SQL注入、权限绕过、越权操作等常见Web攻击完全无效，无法单独作为应用的整体安全防护方案
• 如果站点存在XSS漏洞，攻击者可以直接读取当前页面存储的CSRF Token，也可以直接在用户的合法会话下发起带正确请求头的请求，此时CSRF防护完全失效
• 若服务端CORS配置不当，放开了第三方域名的自定义请求头访问权限，该防护方案也会被直接绕过
• 目前主流的CSRF防护方案为多层组合方案：请求头CSRF Token + SameSite Cookie属性配置 + 关键操作二次校验，整体安全性远高于单独使用请求头CSRF Token的方案

内容的提问来源于stack exchange，提问作者CyberInsects