Python Django安全中间件配置清单

Django的安全中间件并不是开启就完事了。很多配置项的默认值偏向于兼容性而非安全性，直接部署到生产环境往往会让你的应用暴露在常见的Web攻击之下。我们需要把中间件看作一层层滤网，每一层都要精确校准，才能在不影响业务的前提下把风险降到最低。

SecurityMiddleware是Django安全体系的第一道防线，但它默认只处理HTTPS重定向和部分头部注入防护。你需要检查的第一项是SECURE_HSTS_SECONDS。这个值如果设为0，HSTS策略等于没开。对于已经稳定运行HTTPS的站点，建议先从小值开始，比如3600，确认无误后直接提升到31536000（一年），同时把SECURE_HSTS_INCLUDE_SUBDOMAINS设为True，SECURE_HSTS_PRELOAD也设为True，这样浏览器就会把你的域名内置到预加载列表中，从第一次访问就强制走HTTPS。

接下来是SECURE_CONTENT_TYPE_NOSNIFF和SECURE_REFERRER_POLICY。前者阻止浏览器MIME嗅探，必须设为True；后者控制Referer头的发送策略，建议设为same-origin，这样既不会在跨域请求中泄露路径信息，又能保证同源请求携带完整的Referer用于CSRF校验和统计分析。SECURE_CROSS_ORIGIN_OPENER_POLICY同样重要，设为same-origin可以防止其他网站通过window.opener操纵你的页面，这是防范Tabnabbing攻击的关键一步。

Session中间件的配置很多人只关心过期时间，却忽略了更底层的问题。SESSION_COOKIE_SECURE必须设为True，否则HTTPS下传输的Session ID仍可能通过HTTP泄露。SESSION_COOKIE_HTTPONLY默认是True，但你要确认一下有没有被误改为False，这个属性阻止JavaScript读取Cookie，是防御XSS窃取Session的核心手段。SESSION_COOKIE_SAMESITE建议设为Strict或Lax，Lax在大多数场景下更实用，允许用户从外部链接点进来时携带Session，但阻止跨站请求伪造中的Cookie发送。

还有一个容易被忽略的点：SESSION_EXPIRE_AT_BROWSER_CLOSE。如果你的应用涉及敏感操作，建议设为True，让浏览器关闭时清除Session。对于需要长期登录的场景，则必须配合SESSION_COOKIE_AGE设置合理的超时时间，同时在用户执行支付、修改密码等敏感操作前强制进行二次身份验证。另外，SESSION_ENGINE不要使用基于缓存的简单方案，除非你确认缓存服务本身有持久化和高可用保障，否则使用数据库或基于签名的Cookie后端更稳妥，签名Cookie后端要注意SECRET_KEY的强度。

CSRF中间件默认保护所有POST、PUT、DELETE等改变状态的方法，但实际业务中经常会遇到需要豁免的接口。不要图省事直接用csrf_exempt装饰整个视图，这等于把大门敞开。正确的做法是：对于确实需要豁免的API端点，比如接收第三方Webhook回调的接口，单独使用装饰器，并在该视图中增加自定义的签名校验或IP白名单机制作为替代防护。

CSRF_COOKIE_SECURE同样要设为True，CSRF_COOKIE_HTTPONLY需要保持False，因为前端需要读取这个Cookie的值并放到请求头里。CSRF_TRUSTED_ORIGINS是Django 4.0之后引入的配置，用于替代CSRF_TRUSTED_ORIGINS的旧版写法。如果你的前端和后端部署在不同子域，或者使用了反向代理，必须把前端的源地址加到这个列表里，否则所有跨域请求都会被拦截。格式要写成https://subdomain.example.com这样的完整源，不能省略协议。

XFrameOptionsMiddleware默认将X-Frame-Options设为DENY，这是最严格的策略，禁止任何页面被嵌入iframe。但如果你有部分页面需要被同源的iframe嵌入，比如后台管理系统中预览功能，可以改成SAMEORIGIN。更灵活的做法是关闭这个中间件，改用Content-Security-Policy的frame-ancestors指令来精确控制。CSP可以指定允许哪些源嵌入你的页面，粒度比X-Frame-Options细得多。

说到CSP，Django没有内置完整的CSP中间件，但django-csp这个第三方库几乎是标配。部署CSP的策略应该从报告模式开始，设置Content-Security-Policy-Report-Only头，收集一段时间内的违规报告，分析哪些资源被误拦，逐步调整策略，最后再切换到强制模式。script-src要严格限制，避免使用unsafe-inline和unsafe-eval，除非你的前端框架确实需要，这种情况下要用nonce或hash机制替代。style-src同理，尽量减少内联样式。

项目里自己写的中间件往往是安全短板。审查自定义中间件时，重点看三个地方：一是是否直接操作了request.META中的HTTP头，这些值来自用户输入，必须做严格的类型校验和长度限制；二是有没有在响应中拼接用户可控的数据，这可能导致响应头注入；三是中间件的执行顺序，Django中间件按照MIDDLEWARE列表从上到下执行请求阶段，从下到上执行响应阶段，安全相关的中间件应该尽量靠前放置，确保恶意请求在到达业务逻辑之前就被拦截。

如果你的中间件需要记录请求日志，注意脱敏处理。密码、Token、身份证号等敏感字段绝不能明文写入日志。可以在中间件里对request.POST或request.body做一次浅拷贝，把敏感字段替换为星号后再传给日志模块。另外，中间件里捕获异常时不要直接把异常堆栈返回给客户端，生产环境必须返回通用的错误页面，详细信息只记录在服务端。

除了中间件自带的头部，你还需要检查一些额外的安全头。X-Content-Type-Options设为nosniff，防止MIME嗅探。X-Permitted-Cross-Domain-Policies设为none，禁止Flash等插件跨域读取资源。Referrer-Policy前面提过，但要注意如果你的站点有下载文件或跳转到外部链接的功能，可能需要设为strict-origin-when-cross-origin，在同源请求中发送完整Referer，跨域只发送源，降级时不发送。Permissions-Policy是一个容易被忽视的头，它可以限制浏览器特性的使用，比如禁用麦克风、摄像头、定位等API，根据业务需求最小化开放。

Cross-Origin-Resource-Policy和Cross-Origin-Embedder-Policy这两个头在需要资源隔离的场景下很有用。如果你的应用不打算被其他网站引用图片或字体等资源，可以设置Cross-Origin-Resource-Policy为same-origin。Cross-Origin-Opener-Policy前面提到过，配合Cross-Origin-Embedder-Policy可以实现跨域隔离，这是使用SharedArrayBuffer等高性能API的前提条件，但开启后会影响跨域资源加载，需要仔细评估。

手动检查这些配置项效率低且容易遗漏。可以在项目的测试套件里加入安全配置的自动化校验。写一个Django管理命令或者pytest测试用例，用django.conf.settings逐一检查关键配置项的值，比如SECURE_HSTS_SECONDS是否大于0、SESSION_COOKIE_SECURE是否为True、CSRF_COOKIE_SECURE是否为True等。还可以用requests库对本地启动的Django服务发送测试请求，验证响应头中是否包含预期的安全头及其正确值。

更进一步，把安全配置检查集成到CI流水线里。每次代码提交时自动运行安全测试，发现配置降级或误改立即阻断构建。这种自动化验证比依赖人工代码审查可靠得多，也能防止运维在线上修改配置时不小心关掉了某个关键开关。对于HEAD请求和OPTIONS请求也要测试，确保安全中间件对这些HTTP方法同样生效，有些中间件实现只处理GET和POST，这会在特定攻击路径下留下缺口。

当Django部署在Nginx或其他反向代理后面时，安全中间件的部分功能需要配合代理配置才能正常工作。SECURE_PROXY_SSL_HEADER这个配置要谨慎设置，它告诉Django信任哪个HTTP头来判断请求是否来自HTTPS连接。通常设为('HTTP_X_FORWARDED_PROTO', 'https')，但前提是你的反向代理必须在最外层剥离掉客户端伪造的这个头，否则攻击者可以伪造HTTPS标记绕过安全限制。Nginx端要配置proxy_set_header X-Forwarded-Proto $scheme，并确保这个头不会被上游的客户端请求覆盖。

USE_X_FORWARDED_HOST和USE_X_FORWARDED_PORT默认是False，如果你的应用需要根据Host头生成绝对URL，且经过了代理，需要开启这两个选项，但同时要验证代理已经正确设置了X-Forwarded-Host头，防止Host头注入攻击。ALLOWED_HOSTS的配置在代理环境下也容易出错，要确保包含代理服务器的IP和你的实际域名，但不能使用通配符*，那会让Django的Host头验证形同虚设。

安全中间件的配置不是一次性的工作。每次Django版本升级，都要查阅发行说明中关于安全中间件的变更，新版本可能会引入新的安全头支持，或者修改现有配置的默认行为。同时，定期用OWASP ZAP或Burp Suite对站点做被动扫描，验证中间件配置的实际效果，自动化测试只能验证配置项的值，真实的安全头下发情况还需要用扫描工具确认。把这些检查纳入定期的安全巡检流程，才能让中间件这层防线始终保持有效。