在生产环境中，您通常希望披露尽可能少的信息。为此，最好显示通用错误代码：

• 客户端相关错误的错误 400：错误请求、需要身份验证等。
• 与服务器相关的错误 500：数据库关闭、站点关闭以进行维护等。

理想情况下，您不应该选择您的网络服务器提供的默认错误页面。您要么制作自己的错误页面，要么编辑默认错误页面以隐藏任何可能被攻击者使用的信息。例如，以下是我们的一台服务器在访问受密码保护的 URL 时出现的错误：

除此之外，这是一个纯粹的可用性问题，并且很大程度上取决于案例。您不应该将用户重定向到主页吗？这些区域是否受密码保护？您应该查看登录表单吗？或者您只是想用您网站的样式显示一般错误消息？

这是我们网站上的错误页面示例 (Security.StackExchange)

正如@Adnan 所说，在任何生产环境中，您都希望限制信息泄漏。重定向对攻击者也很有用。

我会更进一步地提出建议，并说您不仅应该限制错误的类型，而且还应该只向最终用户提供定制的错误页面。

默认的 400 或 500 页通常包含有关错误的大量信息，这对攻击者非常有用——他们可以找出正在运行的软件、Web 服务器、操作系统等。

因此，错误上下文中的一般建议是向用户提供一个自定义页面，该页面承认错误但不提供任何内容，例如：

内部应记录所有错误，以便对其进行处理。

是的，这意味着身份验证成功，但该帐户无权查看此资源。根据RFC2616，可以改用 HTTP 404。但是我建议不要这样做，因为返回 403 提供以下好处：

1. 对于具有多个帐户（即活动目录）的系统，这为用户提供了必要的信息，他们可能使用错误的帐户登录并应该尝试另一个。
2. 如果用户合法地需要访问权限，则可以在知道他们收到 403 的情况下快速处理帮助台票证。

在您的场景中，“坏人”已经成功登录。希望授权过程足够健壮以阻止进一步的损害（即不要使用查询字符串）。

虽然许多人评论关闭详细的错误消息，但我同意这是最佳实践。但是，403 与服务器错误（例如 HTTP 500）有很大不同，后者将有趣的信息打印到屏幕上。同样，403 仅表示您在成功登录后无权查看特定资源。因此，请继续返回 403，但不要包含详细的诊断信息。

如果这是一个极其敏感的资源，请考虑将其隔离并要求双重身份验证。这将提供额外的安全性，使该人在访问受保护的资源时确实是他们声称的身份。

要回答您的第一个问题，向最终用户显示此错误是不好的。

显示包含确切技术细节的默认错误页面不是一个好的做法。它同时存在安全和用户体验问题。

如果用户是非技术人员，那么这种错误消息可能会使他对其中的所有技术内容感到非常恼火。他将不知道如何解决他力不从心的错误。

另一方面，如果用户是技术人员（可以说是技术人员），他就有机会了解或了解您的应用程序的安全结构。如果他发现了您的应用程序中的安全模式，则很有可能被暴露，因为他试图破坏您的应用程序的攻击将是准确的，或者至少更具体一点。

要回答您的第二个问题，重定向到其他页面似乎不是一个用户友好的好主意。

当用户尝试访问某些内容并将他直接重定向到主页或任何其他页面时，它会破坏可用性和用户对您的应用程序的兴趣。如果您真的想将他重定向到某个地方，请向他展示一条简洁的自定义消息，然后重定向他。这样他至少会知道发生了什么。

错误处理是您问题的解决方案。准备错误消息时，请始终站在用户的角度思考。Show 自定义用户可以轻松理解的错误消息，并且不会暴露应用程序的任何安全结构。

底线-在通知用户之前，必须处理和定制任何类型的错误。