咨询单页应用（SPA）中初始化CSRF Token的简便安全方案

针对你梳理的三种方案，先明确核心结论：

• 方案a：额外请求逻辑成本高，不推荐作为首选
• 方案b：豁免登录请求的CSRF保护绝对不安全，登录接口是CSRF攻击的核心目标之一，攻击者可通过恶意页面诱导用户完成冒用身份的登录操作，严禁豁免；多端点SSO场景下的重复初始化问题也无法解决
• 方案c：单端点场景可行，但多端点适配复杂，额外后端请求成本没必要

推荐方案：Cookie+页面嵌入/响应头结合的初始化方式 #

核心流程 #

1. 后端初始化Token：用户首次访问SPA（或会话中无有效CSRF Token时），后端通过Set-Cookie设置一个非HttpOnly的CSRF Cookie，同时将Token嵌入到SPA的初始HTML（比如<meta name="csrf-token" content="xxx">）或通过静态资源接口的响应头返回。
   • Cookie需配置SameSite=Strict/Lax、Secure（HTTPS环境）、Path=/，确保仅同域/同主域请求能携带。
2. 前端读取Token：SPA加载时，直接从页面meta标签或Cookie中读取Token，存入全局状态（如Vuex、Redux或全局变量）。
3. 请求携带验证：所有非GET/HEAD/OPTIONS的请求，统一在请求头（如X-CSRF-Token）中带上该Token；后端验证时，对比请求头的Token与Cookie中的Token是否一致，同时校验Cookie的安全属性。

痛点解决细节 #

• 无需额外前置请求：首次加载SPA时已完成Token初始化，前端不用编写Token缺失时的请求拦截、重试逻辑，直接读取即可使用。
• 登录请求无需豁免：登录请求作为POST操作，直接携带初始化好的Token即可，完全符合CSRF防护要求。
• 多端点SSO场景适配：
  • 同主域多端点：将Cookie的Domain设置为根域名（如.yourdomain.com），所有子域SPA均可共享该Cookie，无需重复初始化。
  • 跨域SSO：用户在SSO认证中心完成登录后，认证中心返回包含CSRF Token的跳转响应，同时在业务域设置对应的Cookie；前端跳转到业务域SPA时，直接读取Cookie或跳转携带的Token即可。

关键安全注意事项 #

• 禁止将CSRF Cookie设为HttpOnly=true，否则前端无法读取并放到请求头中。
• CSRF Token需具备随机性和唯一性，每个用户会话对应独立Token，会话过期时Token同步失效。
• 跨域API场景：需配置CORS允许携带凭证（Access-Control-Allow-Credentials: true），前端请求需开启withCredentials: true，确保Cookie能被正确携带。

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