按框架
Django 安全 — DEBUG、SECRET_KEY 与授权
Django 的默认值稳固，但事故来自配置：生产环境 DEBUG=True（配置/密钥暴露）、SECRET_KEY 泄露、以及单薄的授权。设置 DEBUG=False、从环境变量加载 SECRET_KEY、显式做授权。以防御视角讲解，不含攻击步骤。
面向：在 Django 上运营应用的人。这里不讲攻击步骤——只讲如何让安全默认值持续生效，同时堵住配置开出的缺口。要看全局，请参阅 按框架的安全防护入口。
三大陷阱（都出在配置里）
Django 的默认值很出色，但下面这三项要由你在配置和代码中守护。
① 生产环境 DEBUG=True
错误页暴露配置、环境变量、密钥。可被故意触发错误提取出来。
② SECRET_KEY 泄露
签名/会话/CSRF 的根基。泄露就有伪造和篡改的风险。
③ 单薄的授权
已认证但缺失权限/所有者检查。换个 ID 就能看到别人的数据。
此外还要留意：通过 raw()/extra() 或字符串拼接导致的 SQLi、不安全的反序列化（pickle）、未设置的 ALLOWED_HOSTS、以及未打补丁的依赖（pip）CVE。
如何堵住这些缺口（3 步）
生产环境 DEBUG=False + ALLOWED_HOSTS
ALLOWED_HOSTS。不要把详细错误对外展示，并为生产环境配置好静态/媒体文件服务。把它固化进部署流程，每次都验证。从环境变量加载 SECRET_KEY 并保密
SECRET_KEY 放进代码/仓库——从环境变量或密钥管理器加载。让它远离公开目录和 DEBUG 页面，一旦泄露立即轮换（→ 不把密钥放进公开目录）。让授权显式化并切断危险的输入路径
raw() 中做字符串拼接，也不要用 pickle 还原不受信任的数据。让依赖（pip）保持 CVE 监控 + 快速打补丁（→ IDOR 是什么）。常见（危险）
- 生产环境放着
DEBUG=True SECRET_KEY硬编码在代码/仓库里- 没有授权——“已登录＝能看”
raw()字符串拼接 · 对不受信任的数据用pickle
正确
- 生产环境 DEBUG=False + ALLOWED_HOSTS
-
SECRET_KEY来自环境变量并保密 - 显式的授权（权限/所有者范围）
- ORM/占位符，不反序列化不受信任的数据
本站的视角：开箱即用，但配置和授权归你自己
Django 默认守护了很多，但生产环境配置（DEBUG/SECRET_KEY/ALLOWED_HOSTS）和授权，是你必须按每个环境、每个应用做对的东西。我们反复看到的事故，与其说是精巧的攻击，不如说是配置/运营的老套路：“调试在生产环境开着”“密钥被暴露”“根本没有授权”。所以重心在于：收紧生产环境配置、让密钥保密、并让授权显式化。不去毁掉那套稳固的默认值，正是运营 Django 的关键。
接下来读
- 入口：按框架的安全防护 · Laravel 安全（生产环境 DEBUG / 密钥暴露相似）
- 密钥：不把密钥放进公开目录 · 实操：漏洞应对实务
- 术语：IDOR 是什么 · SQL 注入是什么
FAQ
QDjango 是一个安全的框架吗？
Django 是『开箱即用（batteries included）』——基于 ORM 的 SQL 防护、CSRF 防护、模板自动转义、以及认证系统都是标配。配置得当它是一个稳固的框架，但事故不是来自核心，而是来自配置。生产环境 DEBUG=True、SECRET_KEY 泄露、单薄的授权，与其说是 Django 特有的问题，不如说更多是运营/配置层面的问题。
Q生产环境把 DEBUG=True 放着不管有什么危险？
开着 DEBUG 时，错误页可能显示详细的内部信息——配置、环境变量、堆栈跟踪。攻击者可以故意触发错误来把它们提取出来。生产环境务必设置 DEBUG=False，并正确配置 ALLOWED_HOSTS。同时不要把详细错误对外展示，并审视生产环境下的静态/媒体文件服务。
QSECRET_KEY 为什么重要？
SECRET_KEY 是签名 cookie 与会话、CSRF 令牌、密码重置等诸多机制背后的密钥。一旦泄露，就可能导致对它们的伪造或篡改。不要把 SECRET_KEY 放进代码或仓库——从环境变量或密钥管理器加载，一旦泄露立即轮换。同时要防止它通过公开目录或 DEBUG 页面被暴露。