在两个要求之间进行权衡：显示什么以帮助用户并帮助调试，以及向用户隐藏什么作为另一层防御。

返回 400“错误请求”而不是更具体的错误代码肯定会产生误导，因为此错误代码与格式错误的请求有关。它会迷惑攻击者，但也会迷惑您系统的目标用户，从而可能降低客户满意度并增加您的支持成本。使用 TLS 可以看到过于通用的错误消息的问题，其中通常只会出现通用的“握手失败”，这使得很难弄清楚潜在的问题是什么。

但是，以“不在源 IP 白名单上”之类的非常具体的原因返回 403“禁止”可能会揭示有关此保护层的太多信息。相反，通用 403 仅表示存在访问控制，并且不会透露任何有关其详细信息的信息。这可能是在不透露太多内部结构和允许集中调试问题之间的一个很好的权衡。

除此之外，还有一些特定的错误代码会在客户端触发操作：401 和 407 将（在交互使用中）导致提示输入身份验证凭据，因此在请求身份验证时不应简单地将它们替换为普通的 400。

如果错误代码与请求一致，则返回误导性错误代码是有意义的。400 不是通用错误代码，但仅适用于格式错误的请求。恕我直言，将其返回以获得完全正确的请求是一个坏主意。

403 仅表示不允许该请求，但没有透露确切原因，因此我认为对于来自未经授权的域的请求始终返回它可能不是问题。或者，404（不存在的 URL）也可以用作一般错误。

老实说，我会坚持使用 403。想象一下，一个有效的用户将它带到其他地方，并尝试从那里连接来自未经授权域的 IP。出于安全原因，您需要拒绝该请求。告诉他们该请求是未经授权的确实是有道理的，他们可以猜到原因。但是给出不同的错误可能会让他们花时间尝试修复网络（本地代理）问题，并最终导致糟糕的用户体验，即使有任何额外的安全性也很少。

如果它在您的组织中很常见，那么我无法想象有充分的理由不遵循它，但如果这只是同事的一个想法，恕我直言，您可以放心地忘记它......

我同意其他贡献者的观点。正如@MechMK1 所说，告诉潜在攻击者他们的 IP 地址未列入白名单并不能为他们提供任何真正的优势。

您的开发人员提出的建议只会使开发人员的测试和调试变得更加困难，因为他们必须始终牢记他们不能相信他们收到的错误代码。更不用说单元测试了。

由于这是一个使用适当 HTTP 状态代码的 REST API，因此更加重要，因为它们被检查以确定请求的结果。

但这让我感到困惑：

我们只接受来自特定域名的请求

您是指 IP 地址还是对远程主机执行反向 DNS？请注意，PTR 记录可能会被欺骗。

如果 API 有专用的域名或 IP 地址，您也可以在防火墙级别执行白名单，这样未经授权的 IP 地址甚至没有机会与托管 API 的网站进行交互。

请注意，在潜在的攻击者甚至收到 403 响应之前，他们应该弄清楚如何向您的 API 发送有效请求（除非您的 API 是公开记录的）。在那之前，他们实际上应该得到 400 个错误，正是因为他们的查询格式不正确并且不是预期的格式。

这看起来与其他请求非常相似，因为我也同意最好显示明确的信息。

请注意，您应该应用 IP 白名单作为第一个检查。即你不解析json参数，如果错误则报400，然后发出403。或者，更极端的情况，检查密码是否错误，只有正确，然后验证源IP。不，最好先检查 IP，如果 IP 地址未经授权，则尽早失败，而不解析任何数据。†

此时，详细错误提供的唯一信息是您正在检查源 IP。无论如何都很难猜到的东西[如果不是直接（几乎）在最终用户的文档中说明]，而且他们无论如何都不能“绕过”（希望如此）。‡

我会更进一步，建议不仅要说“您的 IP 地址未列入白名单”，还要说检测到的 IP 地址，例如“此处不允许使用 198.51.100.85”。

Anonymous提到这将使开发人员的测试和调试更加困难，但我补充说，不仅测试会受到阻碍，生产也会受到阻碍。

如果它仅在内部使用，则更详细的错误可能有助于系统管理员或开发人员在设置 API 时部署连接到 API 的系统（或在某些未宣布的路由更改后突然发现它不再工作时）。

如果它也被最终用户使用，它将更加有用，对于最终用户（“D'oh！，我需要从 X 连接”）和您自己的支持必须在“它不起作用时帮助用户” ”。如果幸运的话，在询问“您是否从白名单 IP 访问？”时 您可能会收到一个明确的“不，我们在 2 个月前更改了它，我们的连接 IP 地址现在是 X”。其他人甚至不知道他们的公共 IP 地址是什么，声称他们正在从 IP 192.168.1.3 连接（到您的互联网系统）......

?

† 通常在防火墙级别列入白名单，在这种情况下，它甚至不会到达应用层。

‡ 为了绕过 IP 过滤器选项基本上是执行 BGP 劫持、控制服务器和白名单客户端之间的中间路由器或让客户端打开恶意网页以代表您发送恶意请求（假设 API不会拒绝以这种方式发生的事情）。如果 API 需要满足代理转发原始 IP 地址的需求（例如 X-Forwarded-For 标头），则其处理可能存在允许额外绕过的漏洞。