将 .NET PDB 文件保留在真实服务器上是否存在任何安全问题？
我知道抛出异常可能需要更长的时间，但是谁会在正常执行期间抛出异常呢？ :-)
但是从安全角度来看呢？有什么问题吗？
如果您的系统在使用 PDB 时不安全，那么如果没有它们，系统也可能不安全。显然，这取决于更好的错误报告对您的价值有多大。就我个人而言，我非常看重这一点，因此倾向于部署 PDB。
我认为一个公平的论点是，不将 PDB 留在实时服务器上是一种风险。在生产崩溃并且问题无法在开发或 UAT 上重现的情况下，诊断错误发生的位置会更加耗时（而且可能是不可能的）。
至少，与部署的 DLL 相匹配的 PDB 应该位于生产服务器上某处的 ZIP 文件中。如果您不在身边提供帮助，其他人应该很容易找到它们。
另请参阅 John Robbins 的 PDB 文件：每个开发人员必须了解的内容。
将 .PDB 文件发布到网站时可能遇到的唯一问题是发生异常，并且忘记在 web.config 中设置 CustomErrors 属性。堆栈跟踪将显示文件名和行号，这可能是一个安全问题。
我认为没有任何其他风险。
如果服务器是 IIS，则不需要。如果将这些文件保存在正确的位置（网站中），则不会向公众公开。有时我会在 Web 服务器上找到中间（obj 目录）文件 - 这似乎是意外公开二进制文件的最喜欢的方式。在任何情况下，如果你的 pdb 可见，你的 dll 也可见，这更糟糕。
正如 activa 所指出的，堆栈跟踪对于有或没有行号的黑客来说非常有用。保密。
我假设您可能在真实服务器上运行的任何其他程序（服务等）根本无法公开访问。
基本上 PDB 就在源代码下方，并且 ASP.NET/IIS 也不会阻止它们被下载。
现在人们肯定必须猜测程序集名称，这可能不太可能，但为什么要冒险呢？
嗯 - 对此我倾向于安全警告。我认为你应该有 PDB，但不要在生产服务器上。此外，您应该在任何实时系统上关闭“调试”。调试是令人讨厌的，当你不需要它时你就不想它。
来自斯科特格思里：
在您的 machine.config 中设置部署 Retail=true：
<configuration>
<system.web>
<deployment retail="true"/>
</system.web>
</configuration>
这会覆盖调试、错误和跟踪设置，这将防止计算机本身之外的任何错误泄露。
既然您已关闭调试，没有错误或跟踪，为什么还要将 PDB 部署到生产服务器呢？将它们存储在其他地方，甚至可能是您的开发服务器。从开发到生产的代码升级脚本可以专门排除 PDB，但将它们存档，以便在您需要对生产进行调试时可用。