有没有人想过这样做？

是的，在 defcon 21（视频、幻灯片）上实际上有一个关于这个的讨论。

他们的结论是，使用响应代码作为攻击性安全措施有时会导致自动扫描仪、无法工作的扫描仪以及大量误报或误报严重减慢速度（对于手动扫描，它显然几乎没有作用） .

虽然默默无闻的安全永远不应该是你唯一的防御，但它可以作为深度防御是有益的（另一个例子：建议不要广播所有使用组件的版本号）。

另一方面，REST API 应该尽可能干净，并且故意使用错误的 HTTP 代码进行回复可能会让开发人员和合法客户端感到困惑（对于浏览器来说，这不是问题，因为用户实际上看不到代码）。因此，我不会在您的情况下推荐它，但这仍然是一个有趣的想法。

它实际上不会显着降低攻击者的速度，但会导致任何在您的平台上工作的未来开发人员对您感到非常恼火。它还可能导致您的 HTTP 请求库的某些不错的功能不太好，因为它们使用不正确的信息进行操作。

这是一种通过默默无闻的非常薄弱的​​安全形式。在设计这样的系统时，您应该考虑将攻击者的速度减慢数百年，而不是数十分钟 - 否则您仍然会失败。

与其返回“401 Unauthorized”，不如返回“305 Use Proxy”，即故意混淆。

是的，它会使攻击者感到困惑。但是对于一个受过训练的人来说，它可能不会超过两秒钟。状态码并不是那么有用，主要是在暴力破解文件名时。

假设我有一个有效的密钥，我可以观察到您返回 200 个范围的代码以进行我的身份验证。如果我对我的密钥进行了一些更改，并且对于每个请求您都返回 305，我会立即认为“嗯。似乎开发人员可能搞砸了”。如果您返回随机代码，我会知道这是故意的，我会忽略它们。

对 iOS 应用进行逆向工程的难度有望阻止除最坚定的黑客之外的所有人

是的，它会的，但是因为它只需要一个人来发布它，它再次只是减慢它的速度..

这是通过默默无闻的安全，也就是说它根本不提供太多的安全性。您建议的解决方案只会减慢攻击者的速度，不会阻止他们使用自己的客户端。事实上，根据您的实现，您加密请求的方法实际上可能会通过对加密系统的其他部分进行攻击而降低您的应用程序的安全性。您最好将精力花在尝试保护 api 函数本身（即对它们进行渗透测试并保护它们免受 Sql 注入等攻击），而不是试图阻止未经授权的客户端访问它们。