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

受到思考的启发,同时查看" 资源可用但由于权限无法访问时纠正HTTP状态代码 "这一问题,我将使用相同的方案来说明我的假设问题.

想象一下,我正在建立一个拼车网络服务.

假设如下

GET /api/persons/angela/location

检索用户"angela"的当前位置.只有angela本人和可能会选择她的司机应该能够知道她的位置,因此如果请求未通过相应用户的身份验证,则会返回401 Unauthorized响应.

还要考虑请求

GET /api/persons/john/location

当没有用户名为john时已在系统中注册.没有john资源,更不用说john位置的资源了,所以这显然会返回404 Not Found.或者是吗？

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

(也许用户名来自一小部分大学登录,校园内有一个非常激进的自行车小组,即使你在拼车,也会对车辆的使用情况非常暗淡？他们可以为每个用户提出URL请求,如果他们收到的是401而不是404,则推断出该用户是汽车用户)

为此请求返回401 Unauthorized是否有意义,即使资源不存在且服务器返回200的请求中没有可能提供的凭据集？

实际上,W3C 推荐(RFC2616§10.4.4403Forbidden)做相反的事情.如果有人试图访问资源但未经过适当的身份验证,则返回404,而不是403(Forbidden).这仍然解决了信息披露问题.

如果服务器不希望将此信息提供给客户端,则可以使用状态代码404(未找到).

因此,你永远不会返回403(或401).但是,我认为您的解决方案也是合理的.

编辑:我认为加布是在正确的轨道上.您将不得不重新考虑部分设计,但为什么不:

找不到 - 404

用户特定的权限不足 - 404

一般权限不足(无人可以访问) - 403

未登录 - 401

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

Hackable网址非常适合您希望每个人都能轻松访问的信息.但是,对于RESTful客户端,使用完全不透明的URI没有问题.

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