对于不存在的资源，是否可以返回 HTTP 401 而不是 404 以防止信息泄露？

Question

受到查看问题“当资源可用但由于权限而无法访问时的正确 HTTP 状态代码”时的想法的启发，我将使用相同的场景来说明我的假设问题。

想象一下我正在构建一个拼车网络服务。

假设以下内容

GET /api/persons/angela/location

检索用户“angela”的当前位置。只有安吉拉本人和可能会接她的司机应该能够知道她的位置，因此，如果请求未经过适当用户的身份验证，401 Unauthorized 响应被返回。

请求

GET /api/persons/john/location

还要考虑当没有名为 john 的用户在系统中注册时的 。没有 john 资源，更不用说 john 位置的资源了，因此这显然会返回 404 未找到。或者确实如此？

如果我不想透露 john 是否在系统中注册怎么办？

（也许用户名是从一小部分大学登录信息中提取的，并且校园里有一个非常激进的自行车团体即使您正在拼车，他们也可以向每个用户的 URL 发出请求，如果他们收到 401 而不是 404，则推断该用户是拼车者）

这有意义吗 ？对此请求返回 401 Unauthorized，即使资源不存在，并且没有可能在请求中提供一组凭据以使服务器返回 200？

Answer 1

实际上，W3C 建议 (RFC 2616 §10.4. 4 403 禁止）做相反的事情。如果有人尝试访问资源，但未经过正确身份验证，则返回 404，而不是 403（禁止）。这仍然解决了信息披露问题。

如果服务器不希望
这些信息可供
客户端，状态码404（不是
发现）可以用来代替。

因此，您永远不会返回 403（或 401）。不过，我觉得你的解决办法也是合理的。

编辑：我认为加布走在正确的道路上。您将不得不重新考虑部分设计，但为什么不呢：

• 未找到 - 404
• 用户特定权限不足 - 404
• 一般权限不足（无人可以访问） - 403
• 未登录 - 401

Answer 2

如果用户名是敏感信息，则不要将它们直接放在 URI 中。如果您在表示中使用超媒体，那么您可以让授权的客户端应用程序轻松导航您的 api，而不会泄漏 URL 中的信息。

可破解的网址非常适合您希望每个人都能轻松访问的信息。然而，对于 RESTful 客户端来说，使用完全不透明的 URI 是没有问题的。

一旦消除了用户和 URI 之间的直接关联，就很难从 401 响应代码中推断出任何信息。

Answer 3

在任何情况下都返回 401 Unauthorized，不允许用户查看特定页面，无论该页面是否存在。

来自 RFC 2616：“如果请求已包含授权凭据，则 401 响应表明这些凭据的授权已被拒绝”。

考虑使用单独的凭据列表对不同 URL 进行身份验证的 HTTP 服务器。显然，当请求 URL 时，服务器不应检查每个列表，因此，如果凭据不在该适用列表中，因为 HTTP 请求彼此完全独立，所以返回 401 Unauthorized 是有意义的 如果凭据对于该特定 URL 无效。

此外，403 Forbidden 的描述包括：“授权不会有帮助，请求不应重复。” 相反，如果用户选择使用正确的凭据登录，授权将会提供帮助。

Answer 4

我认为最好的解决方案是，如果用户未经过身份验证而无法查看其中的任何页面，则为类中的每个（潜在）页面返回 403（禁止）。如果用户存在，则对于不存在的内容返回 404，对于存在的内容返回 200。

Answer 5

我认为如果请求是由非用户的客户端发出的，您想返回 401 Unauthorized 就可以了。但是，如果用户发出请求并通过身份验证，那么我认为 401 不是最佳解决方案。如果您认为返回 404 会危及某些用户的安全，那么您可能需要考虑返回 403 Forbidden 或 200 OK，但不要指定位置。如果我查询用户 bob 并获得响应，查询用户 sam 并获得错误响应，无论是 401、403、404 等，那么我可能会得出结论，这意味着用户 sam 不存在。

不指定位置的 200 OK 可能是最隐蔽的解决方案。

编辑：只是为了说明我的建议。如果客户端未获得授权，则返回 401。否则，始终返回 200 OK。

<user-location for="bob">
    <location>geo-coordinates here</location>
</user-location>

<user-location for="sam">
    <location/>
</user-location>

这并不能真正表明 sam 是否存在，或者可能只是当前没有他的任何位置数据。