单页应用(SPA)中CSRF防护与HttpOnly刷新令牌安全问题咨询

你的推论存在明显疏漏，不能直接得出“不需要CSRF防护”的结论，HttpOnly Cookie中存储的refresh token依然存在被恶意利用的风险。

首先你提到的“refresh token本身无法直接访问受保护私有资源，仅用于令牌交换”这个认知是对的，但你忽略了CSRF攻击的核心逻辑：攻击者不需要知道Cookie里的具体值，只要能触发浏览器自动携带对应Cookie向你的接口发起请求，就可能达成攻击目的，哪怕这个接口仅用来交换令牌。

具体的风险点包括：

• 你当前用GET请求实现令牌交换接口本身就不符合HTTP规范（GET应当是无副作用的幂等请求），这类简单GET请求可以被恶意站点通过<img>、<script>标签、甚至普通链接跳转轻易触发。如果你的refresh接口开启了业界推荐的token轮换逻辑（每次换发新access token时同步下发新的refresh token，旧token作废），恶意站点只要诱导已登录用户访问攻击页面，就能自动发起refresh请求，把用户当前有效的refresh token作废，导致正常用户被强制登出，构成稳定的拒绝服务攻击。
• 如果接口存在配置疏漏，风险会进一步升级：比如误开JSONP支持、CORS配置不当允许了不可信源、或者换发的access token被错误写在可被跨域读取的位置，攻击者甚至可以直接拿到有效的access token，完全窃取用户的登录态。
• 不要默认“服务端只处理SPA发起的请求”——服务端没有能力天然区分请求是不是你的SPA发出的，所有自动携带了Cookie的请求在服务端视角没有任何区别，除非你加了额外的校验规则。就算你把接口改成POST，恶意站点依然可以通过提交跨域form表单的方式发起简单POST请求，自动带上Cookie触发同样的问题。

当然如果你的refresh接口没有做token轮换，且CORS配置严格没有疏漏，攻击者确实拿不到换发的access token，直接窃取登录态的风险比较低，但DoS风险依然真实存在，完全不做防护是不妥的。

纯静态托管的SPA有非常成熟的CSRF落地方案，完全不需要依赖服务端渲染注入隐藏表单字段或者meta标签，常用的可选方案按落地成本从低到高列：

• 方案1：自定义请求头校验（最适配你当前架构）
  这个方案的核心前提你已经满足：你已经配置了CORS仅允许example.com源访问API，跨域场景下浏览器默认不允许请求携带自定义头——只有通过CORS预检（OPTIONS请求）校验的可信源，才能成功发送带自定义头的请求。
  落地逻辑非常简单：
  1. 给所有需要校验Cookie的接口（尤其是refresh令牌交换接口）加一层校验：要求请求必须携带一个自定义头，比如X-CSRF-Protection: 1，没有这个头的请求直接拦截返回403。
  2. 你的SPA在发起这些请求时，统一在请求拦截器里加上这个自定义头即可。
     所有CSRF攻击的载体（跨域img/script标签、跨域form表单）发起的都是简单请求，既不会触发CORS预检，也没有能力添加自定义头，会被直接拦截。这个方案几乎没有额外开发量，也不需要修改nginx的静态托管配置。
• 方案2：双提交Cookie（Double Submit Cookie，通用兼容方案）
  这是纯静态站点使用最广泛的CSRF防护方案，原理是利用“攻击者可以触发浏览器携带Cookie发请求，但无法读取跨域Cookie内容”的特性：
  1. 用户登录完成或者首次访问站点时，服务端除了下发HttpOnly的refresh token外，额外下发一个非HttpOnly的Cookie（可以种在api.example.com或者根域.example.com下），值为随机生成的CSRF令牌，比如csrf_token=xxxxxx。
  2. SPA初始化时直接通过document.cookie读取这个CSRF令牌的值，存在内存中。
  3. 后续所有需要防护的请求，把这个令牌放到自定义请求头（比如X-CSRF-Token）或者POST请求体中携带。
  4. 服务端收到请求后，对比请求中携带的令牌和Cookie里的csrf_token值是否一致，一致才放行。
     整个流程不需要在HTML里注入任何内容，Cookie是通过接口响应头下发的，完全适配nginx静态托管的场景。
• 基础兜底配置：SameSite Cookie属性
  不管选上面哪个方案，都建议你给存储refresh token的HttpOnly Cookie加上SameSite=Lax（兼容部分需要同站跳转的场景）或者SameSite=Strict（无跨站Cookie需求时用）属性，现代浏览器会自动拦截跨站请求携带这个Cookie，从根源上降低CSRF风险，目前这个属性的兼容性已经覆盖95%以上的主流用户。

最后补充几个优化建议：

• 尽快把refresh令牌交换接口从GET改成POST，避免被无意义的GET请求意外触发。
• 所有需要Cookie校验的接口可以额外加一层Origin/Referer校验，只允许来源为example.com的请求访问，多一层防护。
• refresh token建议开启轮换机制，每次使用后旧token立即作废，缩小token泄露后的风险窗口。

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