使用simpleJWT与DRF时的CSRF校验问题咨询

1. 当前情况是否正常？ #

完全正常。Django REST Framework（DRF）的认证逻辑是按配置的认证类顺序依次尝试，只要某一个认证类验证通过，后续的认证类就会被跳过。当请求携带有效的JWT Token时，JWTAuthentication会先完成认证，后续的SessionAuthentication不会被执行，自然不会触发CSRF校验。

2. 为什么JWT认证不触发CSRF校验？ #

CSRF攻击的核心是利用浏览器自动携带Cookie的特性：用户在登录状态下访问恶意网站，恶意网站可以诱导浏览器向目标站点发送请求，浏览器会自动带上目标站点的Session Cookie，从而伪造用户操作。

而JWT认证的常规使用方式是将Token放在请求头（如Authorization: Bearer <token>）中，浏览器不会自动将这个头携带到跨域请求里，恶意网站无法获取或伪造这个请求头，因此不存在CSRF攻击的基础。DRF的JWTAuthentication类默认也就不做CSRF校验。

对比Session认证：Session依赖Cookie中的sessionid，浏览器会自动携带该Cookie，所以必须通过CSRF校验来防范跨域伪造请求。

3. 同时配置Session和JWT时仍不触发CSRF的原因 #

DRF的认证流程是顺序执行、短路生效：

• 如果请求携带有效的JWT Token，JWTAuthentication先通过认证，流程直接进入权限校验环节，SessionAuthentication不会被执行，CSRF校验自然不会触发。
• 只有当JWT认证失败（比如请求没有Token、Token过期或无效），才会尝试SessionAuthentication，此时如果是POST/PUT/DELETE等不安全请求，才会触发CSRF校验。

4. 是否存在安全风险？ #

在JWT的标准使用方式下（Token放在请求头，不存储在Cookie中），不存在CSRF风险。但需要注意两个点：

• 不要把JWT存储在普通Cookie中：如果将JWT存在Cookie里且没有设置HttpOnly、Secure、SameSite=Strict等安全属性，就会存在CSRF风险，此时需要手动为视图添加CSRF校验。
• 本地开发阶段只要遵循JWT的使用规范，风险极低，无需过度担心。

5. CSRF校验的触发时机 #

DRF中，CSRF校验仅在以下条件同时满足时触发：

• 视图使用了SessionAuthentication认证类；
• 请求使用了POST、PUT、DELETE、PATCH等不安全的HTTP方法；
• 请求通过Session认证成功。

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