我需要通过我的应用向Google Books API发出请求，该应用的URL中包含API密钥。
我考虑过仅在应用程序中将其创建为文件私有变量，尽管这是一个大问题，因为它随后将被上传到Github。
然后，我想到了环境变量，但听说如果应用程序不是由Xcode运行的，则不包括这些变量。
我知道可以通过这种方式提取密钥，但是我应该担心吗？ 无论如何，用户不能只使用Wireshark或类似的东西并在URL中看到密钥吗？
而且我可以限制密钥，以便仅在从捆绑包ID调用时才有效。
您认为拨打电话的最佳选择是什么？我的意思是，除此之外，该应用每周仅能获得10次下载，因此这不是一个太大的问题，对吧？
答案 0 :(得分：1)
这是否是一个问题，完全取决于您的用例和威胁模型。如果您以任何方式将其包含在应用程序中或从应用程序中发送或发送，请考虑将您的api密钥公开，并考虑人们可以使用它做些什么。它们会对您造成何种程度的伤害？这给您带来了影响。他们会受到激励吗，例如以某种方式为他们带来经济利益？这估计了发生这种情况的可能性。两者合计起来，影响x可能性=风险，您可以接受（不做任何事情），减轻（减少影响或可能性），消除（解决）或转移（例如购买某种保险）。
对于缓解措施，您可以限制api密钥的范围，以便仅可以使用api对它进行处理吗？您可以设置速率限制吗？监视，警报？我不熟悉Books api，但是这些可能会减轻控件的负担。
为消除风险，您不应将api密钥放入应用程序中。您可以设置自己的服务器，该服务器将保留api密钥，并将请求转发给使用thr api密钥扩展的Books api。请注意，尽管您仍然需要在服务器中进行某种身份验证和访问控制，否则攻击者可以将其仅用作oracle，以在实际的Books api中执行任何操作，就像他们拥有密钥一样，仅在此情况下万一他们不需要它。此角色也可以通过某种api网关来实现，该网关还可以向api查询中添加数据。
消除风险显然更加昂贵。防御应该与风险成正比，因此您必须决定是否值得。