我最近阅读了很多关于将敏感信息保护到 React Native 应用程序的帖子和文章。据我了解，您无法完全保护您的敏感信息，而只会让黑客更难获得它们。
因此，从这个角度来看，我想知道从外部服务器（即 Rest API）获取这些敏感信息（即 API 密钥）是否“更安全”。
我解释一下：
我知道中间人攻击，但是让我的移动应用程序调用我的 API 以通过 HTTPS 请求获取 API 密钥会更安全（也更灵活）吗？这样，应用二进制文件中就不会保留敏感信息。
为了保护中间人攻击，我可以经常更改这些 API 密钥值，以便它们仅在短时间内保持有效。
我想听听任何人关于这种系统的优缺点。
【问题讨论】：
标签： react-native security mobile-application api-key
为了让您为我的回答做好准备，我将首先澄清一些关于公共/私有 API 以及关于 谁 与 什么 真正访问您的后端的常见误解。
我经常看到开发人员认为他们的 API 是私有的，因为他们没有文档，没有在任何地方做广告，还有很多其他原因。
事实是，当您发布一个移动应用程序时，它与之通信的所有 API 现在都属于公共领域，如果这些 API 没有适当的身份验证和授权机制，那么它背后的所有数据都可以通过以下方式访问互联网上任何对您的移动应用程序如何工作进行逆向工程的人。即使 API 具有适当的身份验证，它们也可能容易受到其错误实现的影响，并且根据OWASP API Security Top 10 漏洞列表，有些完全缺乏授权机制或存在错误的机制。
我写了一系列关于 API 和移动安全的文章，在文章 Why Does Your Mobile App Need An Api Key? 你可以详细阅读 谁 和 what 访问你的API 服务器，但我将在这里提取它的主要内容：
what 是向 API 服务器发出请求的事物。它真的是您的移动应用程序的真实实例，还是机器人、自动脚本或攻击者使用 Postman 之类的工具手动绕过您的 API 服务器？
谁是移动应用的用户，我们可以通过多种方式进行身份验证、授权和识别，例如使用 OpenID Connect 或 OAUTH2 流。
因此，将 谁 视为您的 API 服务器将能够对数据进行身份验证和授权访问的用户，并将 what 视为制作该数据的软件代表用户请求。
我知道中间人攻击，但是让我的移动应用程序调用我的 API 以通过 HTTPS 请求获取 API 密钥会更安全（也更灵活）吗？这样，应用二进制文件中就不会保留敏感信息。
虽然您确实在应用程序二进制文件中没有任何敏感信息，但您还没有解决问题。在我看来，您的暴露程度更高，因为您现在正在从公共和开放的 API 端点获取 API 密钥。
我之所以说它是开放的，是因为您没有任何保障措施来确保向它发出请求的什么确实是您的移动应用程序的真实且未经篡改的版本。
所以，现在攻击者需要做的就是 MitM 攻击您的移动应用程序或对其进行反编译，以查看您从哪个 API 端点获取 API 密钥以发出请求，然后从他们的自动化脚本/机器人复制该过程，因此，您不再将它们硬编码在应用程序二进制文件中并不重要。
为了保护中间人攻击，我可以经常更改这些 API 密钥值，以便它们仅在短时间内保持有效。
根据上述说明，在 API Keys Service 部分，您甚至可以将 API 密钥限制为仅用于一个攻击者仍然可以成功的请求，因为攻击者将能够查询 API端点来获取 API 密钥，就好像他是 什么后端所期望的那样，是您的移动应用的真实且未篡改的版本。
因此，需要明确的是，我支持 API 密钥轮换，但前提是您可以从安全的外部来源将它们放入您的移动应用程序，但您的方法对互联网上的任何人都是开放的。
我想听听任何人关于这种系统的优缺点。
您所描述的系统不建议实施，因为如果没有得到保护，它只是要求发生的安全灾难。使用 API 密钥保护它只是回到最初的问题，缺点是您将想要远离黑客的敏感信息还给移动设备。
对您来说最好的方法是使用反向代理来保护 API 密钥的私密性和安全性。
因此，从这个角度来看，我想知道从外部服务器（即 Rest API）获取这些敏感信息（即 API 密钥）是否“更安全”。
您正在寻找的是实现一个反向代理，它通常用于保护对第三方 API 和您自己的 API 的访问，方法是让移动应用将 API 请求委托给反向代理，而不是要求API 密钥，用于从移动应用内部生成它们。
反向代理方法将避免在移动应用程序中对多个 API 密钥进行编码，但您仍然需要一个 API 密钥来保护对反向代理的访问，因此您仍然容易受到中间人攻击和静态逆向工程的攻击您的移动应用。
现在的优势在于，您所有的敏感 API 密钥都是私有的，并且在您可以控制和采用尽可能多的安全措施的环境中，以确保请求确实来自后端所期望的，您的移动应用的正版且未经篡改的版本。
阅读我写的文章Using a Reverse Proxy to Protect Third Party APIs，了解有关使用反向代理的更多信息：
在本文中，您将首先了解什么是第三方 API，以及为什么不应该直接从移动应用中访问它们。接下来，您将了解什么是反向代理，以及何时以及为何使用它来保护对移动应用中使用的第三方 API 的访问。
虽然本文重点介绍第三方 API，但该原则也适用于您自己的 API。
当在移动应用程序中实施证书固定以保护 https 通道时，API 请求上的敏感数据会更容易被提取。
我建议您阅读this answer 中的Preventing MitM Attacks 部分，我提出了另一个问题，您将在其中学习如何实现静态证书固定以及如何绕过它。
尽管可以绕过证书固定，但我仍然强烈建议实施它，因为它可以减少移动应用的攻击面。
我建议您阅读this answer 我提出的问题如何保护移动应用程序的 API REST？，尤其是强化和屏蔽移动应用程序部分 ，保护 API 服务器和可能更好的解决方案。
解决方案将使用移动应用证明解决方案，让您的后端高度确信请求来自它所期望的什么，是您的真实且未篡改的版本移动应用。
在回答安全问题时，我总是喜欢参考 OWASP 基金会的出色工作。
OWASP API 安全项目旨在通过强调不安全 API 的潜在风险并说明如何降低这些风险，为软件开发人员和安全评估人员提供价值。为了实现这一目标，OWASP API 安全项目将创建和维护一份 API 安全风险前 10 名文档，以及一个文档门户，用于在创建或评估 API 时提供最佳实践。
OWASP Mobile Security Project - Top 10 risks
OWASP 移动安全项目是一个集中资源，旨在为开发人员和安全团队提供构建和维护安全移动应用程序所需的资源。通过该项目，我们的目标是对移动安全风险进行分类并提供开发控制以减少其影响或被利用的可能性。
OWASP - Mobile Security Testing Guide:
移动安全测试指南 (MSTG) 是移动应用安全开发、测试和逆向工程的综合手册。
【讨论】：