好的，最好在这里举例说明我的意思。

想象一个基于Web的论坛系统，其中用户身份验证是通过系统知道的某种外部方法来完成的。

现在，例如，用户输入了他们无权访问的线程的URL。为此，我应该返回403(禁止访问)，让用户知道他们应该尝试其他身份验证方法，或者返回404，而不让他们知道有可以访问的内容。

假设我返回403，当他们访问尚不存在的主题的URL时，我还应该返回403吗？

编辑：上面的示例更多是一个IRL的示例。

另一个例子，说我暴露了类似的东西

/adminnotes/user

是否有关于用户的管理员说明。现在，返回403将使用户知道关于它们的某些说法。 404不会说什么。

但是，如果我要返回403，可以将其返回给adminnotes / *，这将解决该问题。

编辑2：另一个示例。软删除的问题在这里返回404. 但是，通过正确的身份验证和访问，我们仍然可以看到它们(我想)

解决方案

世界上没有哪个网站可以按照建议进行操作，因此通过此示例，我们可以看到最好遵循标准并在资源不存在时返回404，在资源被禁止时返回403.

通过向用户隐藏特定线程的存在来保护什么"隐私"？

我想说，在他们无法访问的线程上返回403或者404是可以的。在不存在的线程上返回403是一个坏主意。

最重要的是，遵守HTTP规范。返回403代替404不是一件好事。返回404代替403可能是可以的(或者不是很大的错误)，但是我只是让软件说出真相。如果用户只知道一个主题的ID，反正就不多了。而且他可以尝试定时攻击以确定此主题是否存在。

可以说，当我们检测到用户没有正确的访问权限时，我们确实返回了"找不到页面"错误。意图进行黑客攻击的恶意人员很快就会发现，我们将代替拒绝的访问而将其返回。

但是，真正输入错误的URL或者使用错误的登录名等的用户会感到困惑，并且不会无休止地进行解释并发布注释以向客户，TAC等解释立场。以换取什么？

意图是好的，但恐怕我们提出的这项政策可能无法按我们希望的方式制定。

我的建议是：

• 如果不是Exists_Thread，则返回404
• 如果不是User_Can_Access_to_this_Thread，则返回403

我不明白我们为什么要担心URL中的隐私问题。如果是stackoverflow，则可以在QuestionID号后放置任何文本。例如，返回"正确的"错误代码，还是保护隐私？仍然回到这个问题。

我认为我们应该发送307(临时重定向)请求" / adminnotes / user"，以将非特权客户端重定向到" / adminnotes /"。因此，客户端请求" / adminnotes /"，因此我们可以发送回403，因为它是被禁止的。

这样，应用程序将保持与HTTP兼容，并且没有特权的用户将不会对受保护的数据了解太多。

我将进行307重定向到NoSuchPageOrNoPermissions.html，在这里我们可以很好地告诉用户他们输入了错误的URL或者没有权限。

这不会破坏合规性，也不会发出不正确的消息。

如果我们非常偏执，可以在返回重定向之前进行一次随机等待，这样时间分析会更加困难。

至于这里所有的人都问为什么要保护目录试试这些例子

1.用户名

假设我们是ISP，我们为每个用户提供一个网页，网址为www.isp.example / home / USERNAME，电子邮件地址为[email protected]。如果攻击者进行字典攻击，将请求发送到www.isp.example / home / [Random]，并且可以确定该用户名是否有效，我们现在可以生成一个有效电子邮件地址列表，以出售给不良用户。

2.什么文件夹

鲍勃(Bob)正在竞选办公室，他在张贴者上拥有一个帐户，并使用其网站来存储个人信息。但是他通过将其设置为私人文件夹来保护它的公共页面位于：
www.example.com/Bob，他的秘密文件夹是www.example.com/Bob/IceCream，他已将此标记为私有，因此任何请求的人都将获得403. 但是www.example.com/Bob/Cake返回404作为Bobs的秘密冰淇淋不是蛋糕。

爱丽丝记者对鲍勃网站尝试进行字典攻击

• www.example.com/Bob/Cake-404
• www.example.com/Bob/Donuts-404
• www.example.com/Bob/Lollies-404
• www.example.com/Bob/IceCream-403

现在，爱丽丝(Alice)知道鲍勃(Bobs)的秘密，因此可以声名狼藉。

别忘了404在技术上也可以显示信息。例如，我们可以告诉谁没有管理员注释。根据情况，这可能与表明资源确实存在一样糟糕。

我认为，错误不应存在。如果我们提供404，则应该始终是资源不存在的情况。

如果我们要处理敏感信息，则始终可以说用户没有该资源的权限。这并不一定要求资源存在。客户端可能甚至没有权限来知道资源是否存在。因此，我们需要为/ adminnotes /的任何组合提供一个权限被拒绝的错误。

就是说，官方规范似乎不同意，这是官方RFC在http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html上关于错误的说法：

10.4.4 403禁止
服务器理解了该请求，但拒绝执行该请求。授权将无济于事，并且不应重复该请求。如果请求方法不是HEAD，并且服务器希望公开为什么未满足请求，则应在实体中描述拒绝原因。如果服务器不希望将此信息提供给客户端，则可以改用状态代码404(未找到)。

10.4.5找不到404
服务器未找到与请求URI匹配的任何内容。没有迹象表明这种情况是暂时的还是永久的。如果服务器通过某种内部可配置的机制得知旧资源永久不可用并且没有转发地址，则应使用410(已消失)状态代码。当服务器不希望确切显示请求被拒绝的原因，或者没有其他响应可应用时，通常使用此状态代码。

我不是专家，但是我认为在可能存在资源的情况下提供"未找到"的想法很糟糕。我宁愿选择"禁止"，但不能保证资源存在，这意味着我们需要以某种方式进行身份验证才能找到该资源。