python web项目修复csrf漏洞的核心是启用并正确使用反csrf令牌（csrf_token），不能只靠referer校验或静态随机数硬编码；django虽默认启用csrfviewmiddleware，但@csrf_exempt误用、前端漏传x-csrftoken、模板漏写{% csrf_token %}、render_to_response弃用函数及flask未集成flask-wtf等均会导致防护失效。
直接上结论：Python Web项目修复CSRF漏洞，核心是启用并正确使用反CSRF令牌（csrf_token），不能只靠Referer校验或静态随机数硬编码。
为什么Django默认开CSRF但你仍可能中招？
Django在MIDDLEWARE里默认包含django.middleware.csrf.CsrfViewMiddleware，但以下情况会让它失效：
- 视图函数加了
@csrf_exempt却没意识到该接口接收用户敏感操作（比如修改邮箱、删除账号） - 前端用
fetch或axios发POST时没带X-CSRFToken请求头，也没从csrftokenCookie里取值 - 模板里漏写了
{% csrf_token %}，或把它放在<form></form>外导致不被提交 - 使用
render_to_response（已弃用）而非render，导致RequestContext未注入，csrf_token变量为空
Flask项目没装Flask-WTF时怎么补？
Flask本身不内置CSRF防护，裸用request.form等于裸奔。必须手动集成令牌机制：
- 生成令牌：用
secrets.token_urlsafe(32)（别用random模块）存入session['csrf_token'] - 注入模板：在表单内显式添加
<input type="hidden" name="csrf_token" value="{{ session.csrf_token }}"> - 后端校验：每个POST路由开头加校验逻辑——比对
request.form.get('csrf_token')和session.get('csrf_token')，不等就返回403 - 注意：每次新页面加载都要刷新
session['csrf_token']，否则重放攻击可绕过
CSRF Token被窃取的常见入口点
令牌再随机，如果泄露渠道没堵住，等于白做：
-
Set-Cookie响应头没加HttpOnly=False; Secure=True; SameSite=Lax（开发环境Secure可关，但上线必须开） - 把
csrf_token塞进URL参数（如?token=xxx），会被日志、代理、Referer泄露 - 前端JS通过
document.cookie读取后拼到请求体，容易被XSS利用 - API接口返回JSON时，把
csrf_token字段明文塞进响应体，而前端又没做清理，导致被跨域脚本读取
最易被忽略的是：CSRF防护必须和会话生命周期强绑定。令牌有效期不能长于session过期时间，且用户登出时必须主动清空缓存中的令牌——否则攻击者拿到旧session ID仍可能凑齐有效凭证。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
