Django中用Cookie存储JWT时需CSRF吗？如何存储access token？

1. CSRF Cookie与JWT Refresh Token的处理 #

• 必须设置CSRF Cookie。因为你把refresh token存在HttpOnly Cookie中，这类Cookie无法被前端JS读取，但跨域请求（React前端调用Django后端）时，浏览器会自动带上这个Cookie，此时必须通过CSRF保护来防止CSRF攻击——攻击者可能伪造请求触发token刷新或登出，而CSRF验证能确保请求是来自你的合法前端。
• LoginView中需要设置CSRF Cookie：用户首次登录时，后端要在响应中返回CSRF Cookie，让前端拿到并存储（通常浏览器会自动保存）。RefreshView不需要重复设置，只要前端已经持有有效的CSRF Cookie，后续刷新请求就能正常验证。
• 刷新令牌、登出这类会修改/清除Cookie的请求，必须验证CSRF。因为这些操作属于有状态变更的写请求，Django的CSRF中间件默认会对POST/PUT/DELETE等请求验证CSRF，你只要确保前端在发送这些请求时，把CSRF token放在请求头（比如X-CSRFToken）里即可。

2. React前端Access Token的存储选择 #

• 改用Redux（或其他全局状态管理库，比如Zustand、Jotai）比localStorage更优，原因如下：
  • 安全性：localStorage是持久化存储，一旦遭遇XSS攻击，攻击者可以读取其中的access token并长期持有；而全局状态是内存中的，页面刷新后就会清空，即使被XSS读取，只要用户刷新页面，攻击者就失去了token的控制权。当然，页面刷新后你还是需要从localStorage（或HttpOnly Cookie之外的安全存储）重新加载token到全局状态，但这种短暂的存在比持久化存储风险更低。
  • 开发便捷性：全局状态能让你在任意组件中直接获取token，不用每次都写localStorage.getItem('access_token')；还能统一管理token的过期、刷新逻辑，比如在Axios拦截器中检测token过期，自动调用刷新接口，更新全局状态里的token，所有依赖token的组件都会自动同步更新。

内容的提问来源于stack exchange，提问作者Jeroen van der Merwe