python接口csrf防护关键在于令牌生成、分发、校验、绑定四环节闭环；裸用request.form或request.get_json()且不校验即等于暴露敏感接口。
Python接口的CSRF防护不是“开或关”的开关问题，而是令牌生成、分发、校验、绑定这四个环节是否全部闭环。裸用 request.form 或 request.get_json() 而不校验令牌，等于把转账接口直接暴露在公网。
Flask接口没集成CSRFProtect就等于裸奔
Flask默认不提供CSRF防护，app.secret_key 只用于签名 session，不自动生成或校验令牌。必须显式初始化：
- 安装
Flask-WTF后，在应用启动时调用一次CSRFProtect(app)；重复调用无效，也不会报错 - 若不用 Flask-WTF，就得手动管理：
session['csrf_token'] = secrets.token_urlsafe(32)（禁用random模块） - 每次新页面加载（GET）都必须刷新
session['csrf_token']，否则重放攻击可绕过 - 用户登出时，务必执行
session.pop('csrf_token', None)，不能只清 session ID
Django接口因 @csrf_exempt 或漏传 token 报 403
CSRF verification failed. Request aborted 错误多数不是被攻击，而是防护机制正常拦截了非法请求。常见断点：
- 视图加了
@csrf_exempt却用于修改邮箱、删除账号等敏感操作——该装饰器应仅用于真正无状态、无会话依赖的接口（如健康检查） - 前端用
fetch发application/json请求，但没从 Cookie 读csrftoken并设请求头X-CSRFToken - 模板里
{% csrf_token %}写在<form></form>外，或放在其他<input>之后，Django 中间件无法识别 -
MIDDLEWARE配置中，django.middleware.csrf.CsrfViewMiddleware必须排在SessionMiddleware之后、AuthenticationMiddleware之前
AJAX POST 提交 JSON 数据时 token 总是校验失败
浏览器不会自动把表单隐藏字段塞进 JSON 请求体，Content-Type: application/json 下，Django/Flask-WTF 默认收不到 csrf_token 字段。
- 前端必须显式提取：用
document.querySelector('input[name="csrf_token"]').value（别从 URL 或响应体里捞） - 发请求时把 token 加进 payload：
{"username": "a", "csrf_token": "abc123"} - 后端不能只调
form.validate_on_submit()；得先data = request.get_json()，再用MultiDict(data)构造表单实例 - 检查 Network 面板：若 Content-Type 是
application/json，就绝不能依赖传统 form 表单解析路径
CSRF Token 泄露渠道比生成逻辑更致命
令牌再随机，只要泄露路径没堵住，防护就形同虚设。最容易被忽略的是会话绑定和传输控制：
-
Set-Cookie响应头必须带HttpOnly=False; Secure=True; SameSite=Lax（开发环境Secure可关，上线必须开） - 绝对禁止把
csrf_token塞进 URL 参数（如?token=xxx），会被代理、日志、Referer 泄露 - API 返回 JSON 时，别把
csrf_token明文塞进响应体；前端若缓存或打印该字段，XSS 一触发就全暴露 - 令牌有效期不能长于 session 过期时间；
settings.SESSION_COOKIE_AGE和 token 刷新逻辑必须同步
真正难防的不是技术实现，而是“以为开了中间件就安全了”这种认知偏差——CSRF 防护失效，90% 出现在分发与绑定环节，而不是生成本身。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
