React使用JWT认证且满足特定条件时，仍需CSRF Token吗？

答案是：针对/refresh接口需要做CSRF防护，使用access_token的业务接口则不需要，具体分析结合你的场景如下：

一、使用access_token的业务接口无需CSRF防护 #

你的access_token存储在React状态（如Context API）中，属于前端内存存储，请求时需要手动将token放入Authorization头中发送。这种情况下：

• 攻击者的恶意网站无法通过同源策略获取到这个内存中的token；
• 浏览器不会自动携带该token发起请求，攻击者无法构造出带有有效access_token的跨域请求。
  因此这类接口不存在CSRF风险。

二、/refresh接口需要CSRF防护 #

你的refresh_token存储在HttpOnly Cookie中，仅用于调用/refresh接口获取新access_token，这个场景存在CSRF风险，原因如下：

1. CORS无法完全阻止CSRF：
   CORS是浏览器层面的跨域资源访问限制，仅能阻止跨域请求的响应被恶意网站读取，但如果攻击者构造跨域请求（如POST到/refresh），若你的后端为了携带Cookie配置了credentials: true，浏览器会自动带上refresh_token Cookie发起请求——虽然预检请求会被CORS拦截，但如果/refresh误用了GET方法（不符合REST规范的做法），浏览器会直接发送请求，服务器会执行刷新token的操作，可能导致你的refresh_token被消耗或失效。
2. 同域恶意场景无法被CORS覆盖：
   如果攻击者通过XSS漏洞在你的前端页面注入恶意代码，或者用户误入同域名下的钓鱼页面，恶意代码可以直接向/refresh发起请求，此时属于同源请求，CORS不会做任何限制，浏览器会自动携带refresh_token Cookie，攻击者可以间接利用该接口获取新的access_token（即使无法直接拿到token，也可能通过其他方式利用认证状态）。
3. HttpOnly Cookie不防CSRF：
   HttpOnly属性仅能防止XSS攻击窃取Cookie内容，但无法阻止浏览器在发起请求时自动携带Cookie，而CSRF正是利用了浏览器的这一特性。

三、针对/refresh接口的CSRF防护建议 #

• 确保/refresh接口使用POST方法（而非GET），避免浏览器直接发送无需预检的GET请求；
• 在前端生成CSRF token，存储在非HttpOnly的Cookie或前端内存中，请求/refresh时将token放入请求头（如X-XSRF-TOKEN）；
• 后端验证请求头中的CSRF token与Cookie中的token是否一致，一致则允许请求。

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