Django提升安全配置：防XSS与CSRF中间件详解

本文深入剖析Django安全配置中极易被忽视却至关重要的三大隐患：CSRF保护虽默认启用，却常因前端未正确传递token、误用@csrf_exempt或Cookie配置不当而形同虚设；XSS风险则多源于盲目信任|safe、mark_safe()或内联JS拼接用户输入，尤其在富文本和JSON渲染场景下尤为致命；更隐蔽的是中间件顺序错位、DEBUG模式误上线及日志泄露等“低级错误”，足以让所有安全措施前功尽弃——真正决定Django应用安全水位的，往往不是是否启用了防护，而是每一个细节是否经得起生产环境的严苛拷问。

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%确认内容不含