恶意用户可以使用异常和错误信息来绘制 Web 应用程序的 API，因此通常会查看安全检查表以建议仅返回“请联系您的管理员”类型的消息。
另一方面，我们鼓励使用 HTTP 标准，这些标准会推荐诸如
这些似乎都提供了有关 API 的一些信息，即存在这样的调用，虽然您的攻击接近于格式正确的请求，但还不够接近。
是否应该将所有这些 HTTP 请求都转换为相同的错误消息，还是应该遵守标准？
更新：作为应用程序开发人员，我个人更喜欢相当丰富的异常消息，并且不喜欢我工作的大多数应用程序为应用程序返回的所有内容返回 200，并且仅在 ASP.NET 或 IIS 感觉返回时返回非 200 错误非 200 错误。
我想说不要徒劳地试图通过默默无闻地提供安全性来对抗 RFC，当有人插入您的 API 并在服务器真正抛出 500 时收到 200 个代码时，它们会造成更多的麻烦。
老实说：如果你以某种方式获得了我所有 API 签名的列表，我仍然不会在意，并且会整天返回 403。即使在开放的 API 上，您的 500 条消息也应该足够通用，以至于除了“服务器不喜欢输入，请遵循规范等”之外，他们真的不知道会发生什么。
虽然不返回代码可以通过默默无闻提供一些小的安全措施，但作为用户自己了解这些代码都是很有帮助的。如果您的服务器退回 500，作为合法用户，我知道这不是我的错，而不是为虚假的 404 挠头。
仅当您知道存在某种要避免的泄漏时才考虑更改这些错误消息（404 表示您无权了解的用户页面，而 403 将阻止枚举）。改变一切的批发带来的弊大于利。
与迄今为止的其他受访者一样，我同意通过隐蔽性获得的少量安全性并不会超过返回具有语义意义的响应代码的好处。除了通知用户状态外，在日志中记录有意义的数据对于诊断错误、性能问题和分析安全性也很有帮助。
一个警告是 401 错误 - 这通常会导致浏览器提示输入密码，在没有摘要指令的情况下，可能以明文形式发送 - 如果请求未经授权并且（在大多数情况下）身份验证由运行在网络服务器之上的代码处理，然后使用不同的代码（我是茶壶？）。
事实上，我会更进一步，建议您仔细考虑是否可以使用未定义的状态代码传达更多信息。
我假设您已经知道 MSIE 习惯用非 2XX 代码替换返回的 HTML 。
这里有两个方面需要考虑，您需要根据您要保护的内容以及错误代码可能暴露的漏洞做出决定。一方面，明确的错误消息使调试更容易，我说的是基于真实用户体验的调试。最危险的错误是在系统上线之前您从未遇到过的错误。从安全和业务的角度来看，您越快地压制它们就越好。
在更可怕的世界方面，现在的威胁（黑帽）非常复杂。他们会在发起攻击之前对您的操作系统、网络、编程语言、库和高峰运行时间进行指纹识别。向他们提供更多信息是危险的，尤其是在您的系统不经常更新和修补的情况下。允许威胁探测具有身份验证错误的敏感区域会增加您的风险。
也就是说，我倾向于同意 Jeff 和 StrangeWill 的观点。与投机取巧的黑帽相比，您自己的团队可能会更频繁地使用您将隐瞒的信息。除非您所保护的内容具有很高的价值（不仅仅是电子邮件地址和密码），否则快速修复错误的能力对企业来说比拒绝向黑帽提供少量信息更重要（他们仍然会得到反正很多）。