防患于未然：CSRF 防护原理与中间件拦截机制详解
更多内容请见： 《Python Web项目集锦》 - 专栏介绍和目录
文章目录
- 前言：浏览器最致命的“信任危机”
- 第一章：剥开伪装——CSRF 攻击的本质与信任滥用
- 1.1 浏览器的隐秘法则：自动附加凭证
- 1.2 一场静默的劫持：CSRF 攻击推演
- 1.3 POST 请求同样不安全
- 1.4 防御的核心思想：挑战-响应
- 第二章：Django 的防御矩阵——双重 Cookie 验证机制
- 2.1 核心原则：拒绝 GET 请求验证
- 2.2 Token 的诞生：csrfmiddlewaretoken 与 csrftoken Cookie
- 2.3 表单的护身符：{% csrf_token %}
- 2.4 拦截与校验：双重比对的严密逻辑
- 2.5 更高级别的安全：结合 Session 的签名验证
- 第三章：洋葱的守护者——CsrfViewMiddleware 源码级剖析
- 3.1 请求拦截：process_request
- 3.2 响应注入：process_response
- 3.3 深刻启示
- 第四章：前后端分离时代的 CSRF 痛点与救赎
- 4.1 断裂的闭环
- 4.2 DRF 的标准解法
- 4.3 另一种流派：禁用 Cookie，纯 Header 校验
- 第五章：架构的妥协——@csrf_exempt 与 @csrf_protect 的边界
- 5.1 @csrf_exempt：潘多拉魔盒
- 5.2 @csrf_protect：补救的防线
- 5.3 底层机制：反转的控制权
- 第六章：同源策略的新利器——SameSite Cookie 属性
- 6.1 SameSite 的三种模式
- 6.2 SameSite 彻底杀死了 CSRF 吗？
- 第七章：高级配置与性能调优
- 7.1 CSRF_TRUSTED_ORIGINS：反向代理的救星
- 7.2 避免缓存雪崩：Vary 头的威力
- 7.3 Cookie 的作用域：SESSION_COOKIE_DOMAIN 与 CSRF_COOKIE_DOMAIN
- 结语：安全的尽头是敬畏
前言：浏览器最致命的“信任危机”
在 Web 安全的三大常见攻击（XSS、CSRF、SQL注入）中，CSRF（Cross-Site Request Forgery，跨站请求伪造）是最隐蔽、最容易被忽视，却又最具破坏性的一种。XSS 是窃取了你的数据，而 CSRF 则是借用你的身份。它不偷你的密码，而是利用浏览器对“当前会话”的盲目信任，在你不知情的情况下，以你的名义执行你绝对不想执行的操作（如转账、修改密码、删除文章）。
Django 作为一个全栈框架，从诞生之初就将安全性作为核心信条。其内置的CsrfViewMiddleware是业界公认最严密、最标准的 CSRF 防护实现之一。然而，对于无数开发者而言，Django 的 CSRF 机制就像一个黑盒：遇到403 Forbidden (CSRF token missing)就胡乱加上{% csrf_token %}，或者在 API 开发中干脆粗暴地使用@csrf_exempt装饰器一关了之。
这种“头痛医头”的做法，在复杂的微服务架构、前后端分离场景下，往往会引发更多安全漏洞和难以排查的跨域问题。本文将带你深入 Django CSRF 防护的底层引擎，从浏览器的同源策略缺陷讲起，剖析双重 Cookie 验证机制，并彻底拆解 Django 中间件在请求生命周期中的拦截逻辑。只有知其然且知其所以然，才能真正构建坚如磐石的 Web 应用。