基于Vue+Django REST Framework的Todo应用CSRF令牌使用是否正确？

核心问题分析 #

• 存储位置错误：把CSRF令牌存在localStorage是不安全的。localStorage属于前端可直接访问的存储，一旦页面遭遇XSS攻击，攻击者能轻松窃取令牌并发起伪造请求。标准做法是通过Cookie存储CSRF令牌，配合SameSite、Secure等属性，可大幅降低被窃取的风险。
• GET请求无需携带CSRF令牌：CSRF攻击针对的是会修改服务器状态的请求（如POST/PUT/DELETE），GET请求本身设计为幂等、不修改数据的操作，DRF默认不会对GET请求做CSRF校验，额外携带令牌完全没必要，反而增加冗余。
• 令牌获取方式不符合DRF规范：DRF在用户通过会话认证登录时，会自动在响应中设置csrftoken Cookie，不需要后端主动返回令牌给前端。你手动返回并存储的方式，绕开了框架的安全机制，容易引入漏洞。

正确的CSRF实现方案（基于DRF会话认证） #

后端配置 #

确保DRF启用SessionAuthentication（默认已启用），无需额外配置返回CSRF令牌，框架会自动处理Cookie的设置。

前端处理（Vue项目） #

1. 登录流程：直接发送POST请求到DRF登录接口，后端会自动在响应中设置csrftoken Cookie，前端无需手动存储到localStorage。
2. 请求拦截：使用axios拦截器自动从Cookie中读取CSRF令牌，添加到有状态改变的请求头中：

   import axios from 'axios'
   
   axios.interceptors.request.use(config => {
     // 从Cookie中提取csrftoken
     const csrfToken = document.cookie.match(/csrftoken=([^;]+)/)?.[1]
     if (csrfToken && config.method !== 'get') {
       config.headers['X-CSRFToken'] = csrfToken
     }
     return config
   })
   

3. GET请求：不需要携带任何CSRF令牌，正常发送即可。

安全加固 #

后端在设置CSRF Cookie时，添加以下属性：

• SameSite: Lax 或 Strict：防止跨站请求携带Cookie
• Secure: true：生产环境启用HTTPS时，仅通过HTTPS传输Cookie
• HttpOnly: false：必须设置为false，因为前端需要读取Cookie中的令牌（如果是JWT认证则另当别论）

补充：如果使用JWT认证 #

如果你的Todo应用用的是JWT令牌而非会话认证，DRF默认不需要CSRF令牌（因为JWT放在Authorization请求头中，CSRF攻击者无法获取该头）。但要注意JWT的存储：

• 不要存在localStorage，建议存在带HttpOnly、SameSite属性的Cookie中，避免XSS窃取。

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