它可以向攻击者透露实现的细节，从而可以发起更好的攻击。引用 O WASP 页面关于不正确的错误处理：

即使错误消息没有提供很多细节，这些消息中的不一致仍然可以揭示有关站点如何工作的重要线索，以及隐藏的信息。例如，当用户尝试访问不存在的文件时，错误消息通常会指示“找不到文件”。当访问一个用户没有被授权的文件时，它会显示“访问被拒绝”。用户不应该知道该文件甚至存在，但是这种不一致很容易揭示出不可访问文件的存在或不存在或站点的目录结构。

启用调试模式时需要考虑几件事。

1. 信息泄露：框架版本号、配置值、API 密钥。Django 有一些基本的保护措施来清除其异常页面中看起来敏感的设置值，但您不应该依赖此功能。

2. 内存泄漏：一些框架将扩展的调试信息保存在内存中，以允许对请求进行事后自省。这导致本质上是内存泄漏，攻击者可能会使用它来使 web 应用程序崩溃。例如，当 DEBUG=True 时，Django ORM 存储曾经在连接上完成的所有 SQL 查询。

3. 远程代码执行：一些调试框架允许您执行服务器端代码以在异常发生后内省堆栈中的对象。例如，Werkzeug 调试器。

4. 性能：收集这些调试信息可能会导致性能显着下降。我有一些在生产模式下运行不到一秒的 Django 视图，如果你使用 django-debug-toolbar 打开 SQL 日志记录和调试模式，这需要将近一分钟。

所有这些都有一个共同点，即面向调试的功能通常设计用于 localhost 环境，其中安全性从来都不是真正的问题。

举一个您引用的示例，即currently defined Django settings您为站点设置的值的平均值。这些设置存在的事实并不是秘密。您给他们的值（如管理员列表）可能是。

我认为您的误解在于以下推理：

详细的错误页面将允许潜在的攻击者发现有关应用程序源代码的详细信息

真正的问题是详细的错误页面将允许潜在的攻击者发现有关应用程序当前配置的详细信息。

另一个问题是攻击者如何找到有关应用程序源代码的详细信息（例如，哪个应用程序正在运行该应用程序的哪个版本，例如查看是否正在使用更旧、更易受攻击的版本）。是的，详细的错误页面会对此有所帮助，但也有其他方法可以做到这一点。

另外，我要指出，隐藏软件的源代码（即闭源软件）本身就是“通过默默无闻的安全性”。

这样做只是一个好习惯，以避免向攻击者泄露敏感信息或任何有用的提示。向其他人显示调试信息并不是一个真正的漏洞，但无论如何它都可以被视为一个弱点。换句话说，您的调试信息可能会或可能不会向攻击者显示任何有趣的内容，但为了安全起见，您最好禁用它。您真的 100% 确定您的调试信息永远不会显示您想要保密的任何内容吗？我敢打赌答案是“不是 100%”，所以你最好把它关掉。

这是我刚刚编写的一个非常简单的示例：

WARNING: $accounts is not numeric, $accounts is an array;
$accounts = (user1@example.com, user2@example.com, ...)

假设由于某种奇怪的原因，显示了这样的错误。糟糕：用户的帐户将被泄露。当然你可能会说这是不可能的，框架 X 没有转储变量的内容，框架 Y 不能有这样的错误，你永远不会犯这样的错误，等等。但你能确定会一般来说，从来没有发生在你身上？安全使用并关闭它：这很简单，而且不花钱。