有一个 Web 应用程序可以捕获服务器错误并将它们报告给管理员，以便解决错误。这些错误是在较低级别、守护进程等中发生的事情的结果；离 web 层不远。有时，失败的 SQL 语句会冒泡到错误页面，从而暴露一些数据库模式。
报告页面的 URI 与暴露的错误之间没有关联。如果我理解正确，我认为这意味着避免了 SQL 注入的问题，因为没有用于注入的 Web 路径，但想确认一下。
可以访问这些报告的用户也可以登录到服务器本身并访问有问题的数据库，所以如果我们真的想知道架构是什么，我们有办法查看它。
在这种情况下是否需要考虑安全风险？
我认为公认的做法是将错误消息记录到一个中心位置（可能是数据库），并有一个例程来清理显示给用户的消息，以确保不共享敏感信息。
坏人可以将有关您系统的知识用于恶意目的，例如 SQL 注入攻击、拒绝服务器攻击等。
简短的回答是，没有理由将 SQL 错误暴露给用户，特别是如果这是在 Web 应用程序前面的业务用户。这就是为什么我们有“catch”和“throw”。内部异常应该只在调试期间冒泡。否则，应将其保存在日志中。
通常，我们应该监控日志。如果您宁愿等待客户投诉（由于人员限制），您当然可以在您“抛出”的消息中附上与您的日志相关的跟踪号，以说明问题的性质。
如果您在“我们都是朋友”环境中工作，那么通过错误消息暴露模式应该没有问题。但是您对安全性的担忧已经表明情况并非如此。
首先，回答你的问题。
始终存在安全风险。攻击者没有无用的数据。即使无法为您提供特定的攻击场景，也并不意味着没有风险。
接下来，关于在 Web 前端显示系统错误消息的想法。
正如其他人已经说过的那样，总的来说，这是一个非常糟糕的主意。无辜的用户不必看到这些技术细节，而只需要看到一个通用的错误页面。将它们的详细信息透露给 Web 访问者是一个错误。错误最好修复。修复一个 bug 比在 Stack Overflow 上询问这个 bug 是否严重要好得多。