为何将Refresh Token存于HTTP Only Cookie可防CSRF攻击？是否仍存风险？

你的理解完全正确 #

HTTP-Only Cookie的核心特性就是禁止前端JavaScript读取，但是只要请求的目标域名、路径、Secure属性等匹配Cookie规则，不管是本站还是第三方站点发起的请求，浏览器都会自动携带对应的Cookie。所以如果/refreshtoken端点没有额外防护，恶意站点确实可以发起跨站请求，自动带上Refresh Token拿到新的Access Token，这属于标准的CSRF攻击场景。

原文表述的实际含义 #

但通过Refresh Token间接持久化会话，我们可以避免使用JWT令牌时直接存在的CSRF漏洞

这句话的对比对象是「把JWT Access Token也存储在Cookie里」的方案：如果Access Token存在Cookie中，所有业务请求（比如GraphQL的查询、变更接口）都会自动携带Cookie，意味着所有业务接口都需要做CSRF防护，风险覆盖范围极广。

而按照文中的方案，Access Token存储在内存中，请求时放到Authorization请求头里传递，第三方站点完全无法拿到内存中的Access Token，所以所有业务接口都不存在CSRF风险，只有/refreshtoken这一个端点需要处理CSRF问题，风险面被压缩到极小，所以原文表述为「避免直接存在的CSRF漏洞」，并非指完全消除CSRF可能性。

针对/refreshtoken端点的CSRF防护方案 #

• 给Refresh Token对应的Cookie增加SameSite=Lax或SameSite=Strict属性，现在主流浏览器都支持该属性，跨站发起的请求不会携带对应Cookie，从根源上阻断攻击
• 如需兼容不支持SameSite属性的旧浏览器，可以要求/refreshtoken请求额外携带CSRF Token，该Token可以存储在LocalStorage或者非HTTP-Only的Cookie中，请求时放到自定义头或者请求体中，第三方站点无法读取到该Token，即使自动携带了Refresh Cookie也无法完成请求
• 接口层增加Origin/Referer校验，只允许信任的域名发起刷新Token的请求

内容的提问来源于stack exchange，提问作者Shalahuddin Al-Ayyubbi