Django CSRF保护默认启用但易被绕过，因前端未传token或误用@csrf_exempt；CSRF token需Cookie与请求头/表单字段匹配；XSS风险源于|safe等绕过转义操作；中间件顺序、DEBUG配置及日志安全同样关键。
CSRF保护为什么默认开启却还被绕过
Django的CsrfViewMiddleware默认启用，但常见绕过场景是：前端用fetch或axios发POST请求时没带csrftoken，或者后端视图加了@csrf_exempt却忘了只对真正需要的接口豁免。
关键点在于：CSRF token必须从Cookie（csrftoken）和请求头（X-CSRFToken）或表单字段（csrfmiddlewaretoken）中**同时提供且匹配**，中间件才放行。
- 确保前端读取
document.cookie里的csrftoken值，并在请求头设置X-CSRFToken - 避免全局用
@csrf_exempt；如需豁免，优先用csrf_protect包裹特定逻辑，而非直接关掉中间件 - 检查
settings.py中CSRF_COOKIE_SECURE = True（生产环境必须设为True，否则HTTPS下cookie不发送） -
CSRF_COOKIE_HTTPONLY = False——必须为False，否则JS读不到token（Django默认就是False，别手抖改成True）
XSS漏洞常出在模板变量渲染和用户输入回显
Django模板默认对变量使用{{ var }}会自动转义HTML，但一旦用了{{ var|safe }}、{% autoescape off %}或通过mark_safe()返回内容，就等于把过滤器关了——这时候如果var来自用户提交（比如评论、用户名、URL参数），XSS就来了。
- 所有用户输入进模板前，先过
escape再渲染；除非你100%确认内容不含<script>、onerror=等危险片段 - 富文本场景（如CMS后台）不能靠
|safe硬上，改用bleach库白名单过滤：bleach.clean(html, tags=['p', 'br'], attributes={'a': ['href']}) - JS内联渲染用户数据时，绝对不要拼接
innerHTML；改用textContent，或用JSON.stringify()包裹后解析：const data = {{ user_input|json_script:"data" }};
中间件顺序错一位，安全机制就失效
Django中间件执行顺序严格依赖MIDDLEWARE列表顺序。CsrfViewMiddleware必须在SessionMiddleware之后、所有自定义视图中间件之前；而XSS相关的响应处理（如添加Content-Security-Policy头）必须放在最末尾，否则可能被后续中间件覆盖。
立即学习“Python免费学习笔记（深入）”；
- 标准顺序关键段落应为：
'django.contrib.sessions.middleware.SessionMiddleware'→'django.middleware.csrf.CsrfViewMiddleware'→ … → 你的自定义中间件 →'django.middleware.security.SecurityMiddleware' -
SecurityMiddleware要启用SECURE_CONTENT_TYPE_NOSNIFF = True和SECURE_BROWSER_XSS_FILTER = True（后者仅对旧IE有效，但留着无害） - 如果写了自定义中间件用于响应头注入（比如CSP），务必确认它在
SecurityMiddleware之后注册，否则它的X-Content-Type-Options可能被覆盖
DEBUG=True上线等于公开源码+SQL+用户session
开发时方便的DEBUG=True，一旦部署到公网，会直接暴露完整错误堆栈（含路径、变量值、数据库查询）、所有已注册URL路由，甚至能触发django.views.debug.sensitive_data泄露settings.py里未标SECRET_KEY的敏感配置。
- 上线前必须设
DEBUG = False，并配好ALLOWED_HOSTS = ['yourdomain.com']（不能留['*']） -
LOGGING配置里禁用django.request的ERROR级别日志输出到控制台，防止500错误把traceback打到Nginx error log里 - 用
python manage.py check --deploy能快速发现DEBUG、SECRET_KEY硬编码、ALLOWED_HOSTS空值等高危项
真正麻烦的不是加几行中间件，而是CSRF token怎么随AJAX走、CSP策略要不要配unsafe-inline、还有那些藏在json_script和escapejs滤器背后的边界情况——这些地方一松手，前面全白干。
