为每个无效请求抛出 404 错误可能是有问题的，如果攻击者知道他所针对的服务，他可能会开始特别怀疑这种行为。
这是否有助于保护您的服务？这真的取决于攻击者的毅力。

编辑：

如果您没有像服务器那样正确制作 404 响应标头，攻击者可以检测到差异

这是 Java 服务器案例 (Tomcat8) 的 PoC：
这是服务器本身返回的“真实”404 状态任何未找到的资源：

Content-Language:en
Content-Length:1026
Content-Type:text/html;charset=utf-8
Date:Tue, 31 Jan 2017 09:15:54 GMT
Server:Apache-Coyote/1.1

这个由 servlet 返回：

Content-Language:en
Content-Length:992
Content-Type:text/html;charset=utf-8
Date:Tue, 31 Jan 2017 09:18:04 GMT
Server:Apache-Coyote/1.1

在这两种情况下，您都会注意到“Content-length”参数的值，这可能会引起攻击者的注意。

当心，隐藏实际的错误代码有点像混淆。从安全的角度来看，没有什么不好的，但如果有的话，它几乎不会增加安全性。你真的认为攻击者会盲目接受错误码吗？你知道他们可以随意改变，他们也可以。好的，它对脚本小子很有用，但不会面临严重的攻击，所以在这样做之前你应该真正考虑一下你的威胁模型是什么。

这里可能有一个缺点。除非您构建一个记录内部错误的特殊日志系统，否则您的日志将仅包含 404 错误。这意味着您已经失去了进行日志分析以试图发现对您的站点的攻击和可能的安全漏洞的任何可能性。恕我直言，错误代码对应用程序的维护者比对攻击者更有用......

同样的想法也适用于用户身份验证。

如您所见，大多数 Web 服务不会告诉您用户名和密码有什么问题。它会给你一个一般提示，说整对的东西是无效的。这使得攻击者不知道用户名不正确、密码不正确或配对本身不正确。

与用户是否存在 相比，确定用户 是否存在以及密码是否正确要快得多。一些攻击者在尝试按时间访问系统时会考虑到这一点。

同样，对于 404（未找到）与 403（未授权）也是如此。Web 服务器返回 404 比返回 403 更快，但是这里的时间可能非常小，误差幅度可能会接管。

总是吐出 404 而不是 404/403 并非闻所未闻。诸如 Apache 之类的 Web 服务器可以自定义它对网页请求的响应。更改 HTTP 返回码有点困难，但修改用户看到的页面肯定更容易。就像用户名/密码的想法一样，攻击者有两种情况：

• 这个资源真的存在吗？
• 我必须先获得授权才能访问它吗？

现在更常见的是服务器端代码处理授权和身份验证，而无需 Web 服务器返回 404/403 代码。服务器端代码通常会处理此类请求，Web 服务器将简单地返回 200 或 300 代码。页面的内容可能是 403，但 HTTP 代码将是 200 或 300。403 用于 HTTP 身份验证，随着时间的推移已经不受欢迎。