CSRF防护需服务端绑定、一次性/短时效、传输隔离三条件并存，Django/Flask默认防护存在AJAX、JSON接口等盲区，须前后端协同管控token生命周期与传输路径。
Python Web 项目中，CSRF（跨站请求伪造）不是“会不会发生”的问题，而是“什么时候被利用”的问题——只要应用依赖 Cookie 进行身份认证、又没对非 GET 请求做有效防护，攻击就可能成功。
为什么 Flask/Django 默认不完全免疫 CSRF？
Django 自带 csrf_token 模板标签和中间件，但仅对表单 POST 生效；AJAX 请求、JSON 接口、自定义 header 场景下容易遗漏验证。Flask 更是默认不提供 CSRF 防护，需手动集成 flask-wtf 或自行实现 token 管理。常见疏漏包括：
- 前端未在 AJAX 请求头中携带
X-CSRFToken（Django）或X-CSRF-Token（Flask-WTF） - 后端视图跳过
@csrf_protect装饰器，或使用csrf_exempt过度宽松 - 登录/登出接口未启用 CSRF 保护（攻击者可静默触发登出或伪造登录）
CSRF Token 必须满足的三个条件
一个有效的 CSRF token 不是随便生成的字符串，它需要同时满足：
- 服务端绑定：与当前用户 session 或 user ID 强关联，不能全局复用
- 一次性或短时效：每次表单渲染应刷新 token，或设置 1–2 小时有效期，避免泄露后长期有效
-
传输隔离：token 存在 Cookie（
HttpOnly=False）供 JS 读取，但绝不通过 URL 参数或 Referer 传递
绕过常见防护的典型手法
攻击者常利用开发习惯漏洞绕过防护：
立即学习“Python免费学习笔记（深入）”；
- 利用
GET请求修改状态（如/api/user/delete?id=123），因 GET 默认不校验 CSRF - 前端将 token 写死在 JS 变量里，导致所有用户共用同一 token
- API 接口接受
Content-Type: text/plain或application/json，但后端未检查 Origin 或未校验 token（浏览器同源策略不限制这类请求发送）
简单可靠的加固建议
不需要重写整个鉴权体系，从这几个点切入就能显著降低风险：
- Django 项目确保
MIDDLEWARE中启用django.middleware.csrf.CsrfViewMiddleware，并在所有状态变更视图上保留ensure_csrf_cookie()（尤其含 AJAX 的页面） - Flask 项目统一用
flask-wtf.CSRFProtect，配合generate_csrf()在模板中注入，并在 API 视图中调用validate_csrf() - 对纯 API 服务（如前后端分离项目），强制要求每个非 GET 请求携带
X-Requested-With: XMLHttpRequest并校验Origin头（仅允许可信域名） - 敏感操作（转账、改密、删资源）增加二次确认机制，如短信/邮箱验证码，不依赖单一 token
CSRF 防护不是加个装饰器就万事大吉，关键在 token 生命周期管理、传输路径控制和前后端协同。漏掉任意一环，都可能让防护形同虚设。
