一旦攻击者已经可以访问系统，就为时已晚。不泄露密钥的主要问题是因为它经常被用作散列和签名会话的种子。这个想法是您的生产SECRET_KEY需要与您的开发或登台完全不同SECRET_KEY。您实际上可以在每次重新启动时随机生成它，尽管这可能会影响用户体验（请参阅下面的详细信息）。

只要您坚持更改密钥的原则，无论您是否提交（只要您确保从 dev 到 prod 时更改它）都没有太大的危险。如果你不这样做，那么拥有密钥的人可以预测散列算法的结果（用于会话）甚至签署会话。

如果攻击者已经获得了对您系统的访问权限，那么您已经走得太远了，因为它不再是您的系统了。您需要确保的一件事是，您的设置文件的文件权限只能由运行网络服务器的用户读取，其他任何人都不能读取。这可以防止非法访问受限帐户（与网络服务器帐户不同）的人泄露您的密钥。

Stack Overflow 上有一个很好的答案：Django SECRET_KEY由sberder编写，详细说明了它的用途：

• JSON 对象签名
• 用于盐渍 hmacs 或播种随机引擎的加密函数会影响：
  • 密码重置令牌
  • 评论表单安全性以防止伪造 POST 请求
  • 形式安全
  • 防止消息篡改，因为消息框架可能使用 cookie 在视图之间传递消息。
  • 保护会话数据并创建随机会话密钥以避免篡改。
  • 为大多数密码哈希创建随机盐
  • 如有必要，创建随机密码
  • 使用时创建自己 startproject
  • 创建 CSRF 密钥

实际上，这里列出的许多项目都SECRET_KEY使用django.utils.crypt.get_random_string()它来为随机引擎播种。这不会受到 值变化的影响SECRET_KEY。

价值变化直接影响的用户体验包括：

• 会话，数据解码将中断，这对任何会话后端（cookie、数据库、基于文件或缓存）都有效。
• 已经发送的密码重置令牌将不起作用，用户将不得不要求一个新的。
• 评论表单（如果使用django.contrib.comments）将不会验证是否在值更改之前请求并在值更改之后提交。我认为这非常小，但可能会让用户感到困惑。
• 消息（来自django.contrib.messages）不会在与评论表单相同的时间条件下验证服务器端。