django默认启用csrfviewmiddleware且不建议关闭，它校验post/put/delete请求中的csrf token（来自表单字段或x-csrftoken头）与cookie/session中存储的token是否匹配，不一致则返回403；仅靠模板中{% csrf_token %}无法替代中间件的校验功能。
django.middleware.csrf.CsrfViewMiddleware 不是“必须用”，而是**默认启用且不建议关闭**——因为关掉它，等于主动放弃对所有非 GET/HEAD 请求的自动防护层，而这类请求（POST、PUT、DELETE）恰恰是业务操作的核心入口。
CSRF 中间件到底在拦什么？
它不是在防“用户输错密码”，而是在防“用户没点但浏览器替他点了”。典型场景：
- 用户已登录银行后台（会话 cookie 有效）
- 同时打开了攻击者控制的论坛页面（含一段隐藏
form或自动fetch） - 该页面悄悄向银行后端发
POST /transfer，浏览器自动附带银行域名的sessionid和csrftokencookie - 中间件比对请求中的 token（来自 header 或 form data）和 session/cookie 中存储的 token 是否匹配，不一致就直接 403
没有这个中间件，只要攻击者能诱导用户访问恶意页面 + 用户处于登录态，转账、删库、改权限就可能一气呵成——整个过程用户完全无感知。
为什么不能只靠前端加 {% csrf_token %}？
{% csrf_token %} 只负责把 token 塞进 HTML 表单，但它本身不校验。真正做校验的是 CsrfViewMiddleware。常见误解：
- “我模板里写了
{% csrf_token %}，所以安全了” → 错。如果中间件被注释或顺序错位（比如排在SessionMiddleware之后），token 根本不会被解析 - “我用 API 模式，前后端分离，所以不用管 CSRF” → 错。只要前端仍用浏览器原生 cookie 认证（而非 bearer token），CSRF 风险依然存在
- “我只用 AJAX，手动传 token 就行” → 对，但前提是后端中间件开着，且你传的是
X-CSRFTokenheader 或csrfmiddlewaretoken字段，否则中间件照样拒绝
关闭中间件的后果与替代方案
全局关闭 CsrfViewMiddleware 是高危操作，仅适用于极少数明确无状态、纯 token 认证（如 JWT 放 header）、且彻底脱离 cookie 会话的场景。但即便如此，也要确认：
Python 3.14.2
下载
Python 3.14.2是Python编程语言在2025年12月5日发布的稳定版本，属于3.14系列的第二个维护更新。该版本包含了18项修复，重点解决了多进程、数据类及正则表达式等模块的回归问题，并修复了CVE-2025-12084等安全漏洞。此版本标志着自由线程模式（移除GIL）正式获得官方支持，是Python发展的重要里程碑。
-
settings.py中SESSION_ENGINE是否仍依赖 cookie（如django.contrib.sessions.backends.cache仍可能写 cookie） - 是否所有 POST 接口都已显式加了
@csrf_exempt—— 这个装饰器只跳过校验，不解决本质风险 - 是否已用其他机制补位，比如严格校验
Origin/Referer（但这两项可伪造，不可单独依赖）
更稳妥的做法是：保持中间件开启，对特定视图用 @csrf_protect（强化）或 @csrf_exempt（慎用），而不是一刀切关掉。
容易被忽略的细节：token 的生命周期与同步
CSRF token 并非一劳永逸。它和 session 绑定，但有独立刷新逻辑：
- 每次调用
request.session.save()或响应中写入新 session，csrftokencookie 可能更新 - 用户长时间闲置后 session 过期，但前端 JS 仍拿着旧 token 发请求 → 报错
CSRF verification failed. Request aborted. - 前后端分离时，若用
CSRF_USE_SESSIONS=True，token 存于 session 而非 cookie，JS 无法读取 → 必须走服务端接口透出 token
这些细节不处理，就会出现“明明写了 token 却总 403”的问题，根源不在中间件开关，而在 token 的获取、传递和时效协同上。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
