必须将 debug 设为 false，因为 debug=true 会通过调试页面完整暴露 settings、请求数据、执行栈变量等敏感信息；应使用环境变量控制、ci/cd 检查、容器构建隔离，并规范变量命名以触发 django 掩码机制。
必须立刻将 DEBUG 设为 False，否则任何其他补救措施都只是给漏洞打补丁。
为什么 DEBUG=True 在生产环境等于公开配置表
Django 的调试页面不是“多显示点信息”，而是完整 dump 当前 Python 进程的运行上下文。一旦触发 500 错误（比如访问一个不存在的 URL），django.views.debug.technical_500_response 就会把以下内容直接渲染成 HTML 返回给客户端：
• settings.py 中所有变量（包括 SECRET_KEY、DATABASE_URL、EMAIL_HOST_PASSWORD）
• 请求的 POST 数据和 COOKIES
• 执行栈里的局部变量（可能含用户 token、临时密钥）
• 项目绝对路径（暴露服务器结构）
• 已加载中间件和应用列表（辅助攻击者识别技术栈）
如何安全关闭 DEBUG 并防止误开
硬编码 DEBUG = False 不可靠，容易在合并分支或本地调试后忘记改回。推荐用环境变量控制：
- 在
settings.py中用os.getenv('DJANGO_DEBUG', 'False').lower() in ('true', '1', 't')替代直接赋值 - 生产环境部署时，确保系统环境变量中
DJANGO_DEBUG未设置，或显式设为false（注意：大小写敏感，False字符串会被当成True） - CI/CD 流水线中加检查步骤：用
grep -q 'DEBUG.*=.*True' settings.py或更稳妥的python -c "import settings; print(settings.DEBUG)"验证值为False - 容器镜像构建阶段禁止
COPY .env*，尤其不能把含DEBUG=True的.env.local一起打包
即使 DEBUG=False，仍可能泄露敏感配置
Django 默认只对少数几个固定名称（如 SECRET_KEY、PASSWORD）做星号掩码，其他变量名只要没含 secret、key、pass、token 等关键词，就会原样显示在 SettingsPanel 或日志里。常见踩坑点：
-
s3_bucket_key = 'xxx'→ 不会被掩码（缺少SECRET或PASSWORD） -
api_token = 'xxx'→ 会被掩码（含token） -
db_password→ 会被掩码；但database_password→ 不会（Django 只匹配完整单词） - 使用
django-environ时，env.str('S3_KEY')读取的值仍会出现在调试面板，除非变量名本身含敏感词
额外防线：禁用调试工具栏的敏感面板
哪怕 DEBUG=False，如果误装了 django-debug-toolbar 且没配 SHOW_TOOLBAR_CALLBACK，它仍可能在特定 IP 下激活。务必在生产 settings 中明确禁用：
DEBUG_TOOLBAR_CONFIG = {
"SHOW_TOOLBAR_CALLBACK": lambda request: False,
"DISABLE_PANELS": {
"debug_toolbar.panels.settings.SettingsPanel",
"debug_toolbar.panels.request.RequestPanel",
"debug_toolbar.panels.sql.SQLPanel",
},
}
其中 SettingsPanel 是最大风险项——它会列出所有 settings 变量，且不走 Django 的掩码逻辑，完全按变量名判断是否敏感。
真正关键的不是“怎么关掉调试页面”，而是“怎么让敏感信息从源头就不进调试上下文”。命名规范、环境隔离、CI 检查这三步漏掉任何一环，都可能让一次简单的 404 请求变成凭据泄露的起点。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
