你的问题
我目前在 Android 应用程序中使用 Spotify，但我需要使用 Secret 才能刷新令牌等。我想将秘密从我的后端传输到应用程序，因此秘密不驻留在APK中，并且在反编译时无法找到。我读过很多关于保护应用程序中的秘密的内容，通过代理等各种方式，仅使用您自己的后端，将代码放入应用程序中的本机 C++ 代码 (NDK) 或使用应用程序的哈希来确定是否应用程序正在调用后端，而不是他的计算机后面的某个人试图窃取秘密。
恭喜您努力理解这个问题，似乎您在很大程度上了解了移动应用程序中的秘密始终可以通过静态二进制分析来提取，但我没有看到任何提到的仪器框架，例如：
Frida https://www.frida.re/
将您自己的脚本注入黑盒进程。挂钩任何函数、监视加密 API 或跟踪私有应用程序代码，无需源代码。编辑，点击保存，然后立即看到结果。全部无需编译步骤或程序重新启动。
or
xPosed https://repo.xposed.info/module/de.robv.android.xposed.installer
Xpose 是一个模块框架，可以在不接触任何 APK 的情况下更改系统和应用程序的行为。这很好，因为这意味着模块可以适用于不同的版本，甚至无需任何更改的 ROM（只要原始代码没有更改太多）。它也很容易撤消。
但还有许多其他的存在，并且所有这些都将在运行时连接到您的代码并提取您存储在移动应用程序中的任何秘密，无论您存储它的安全程度如何，即使您使用硬件支持的密钥库（在可信执行中运行）环境：
Android 硬件支持的密钥库 https://source.android.com/security/keystore
片上系统 (SoC) 中可信执行环境的可用性为 Android 设备提供了向 Android 操作系统、平台服务甚至第三方应用程序提供硬件支持的强大安全服务的机会。
在某些时候，从该密钥库检索到的秘密将需要用于向第三方服务发出请求，此时攻击者所需要做的就是挂钩对该函数的调用并在传递到时提取秘密它。
因此，无论你最终做什么，移动应用程序中的秘密始终可以被提取，这仅取决于攻击者的技能以及他愿意投入的时间和精力。
话虽如此，这让我意识到我总是建议开发人员不要这样做，那就是从他们的移动应用程序中调用第三方服务。
从移动应用程序访问第三方服务
找到选项：
代理：这意味着通过我自己的服务器路由它，不希望这样
自己的后端：与代理相同，不希望所有请求都通过我自己的服务
是的，我了解到您不想使用代理或后端，但这是您确保访问第三方服务（在本例中为 Shopify）的最佳机会。
I wrote 本文 https://blog.approov.io/using-a-reverse-proxy-to-protect-third-party-apis这解释了为什么你不应该从你的移动应用程序中执行此操作，我引用的是：
一般来说，所有第三方 API 都需要 API 密钥、访问令牌或某种其他机制形式的秘密，以便远程客户端向其希望与之通信的后端服务器识别自己的身份。这就是从移动应用程序中访问它的问题的症结所在，因为您需要在代码中发送所需的秘密（上图中的彩色键）。
现在您可能会说您已经混淆了代码中的秘密，将其隐藏在本机 C 代码中，在运行时动态组装它，甚至对其进行了加密。然而，最终攻击者为了提取这个秘密所需要做的就是反向工程 https://blog.approov.io/how-to-extract-an-api-key-from-a-mobile-app-with-static-binary-analysis具有静态二进制分析的二进制文件，或者挂钩诸如Frida https://frida.re/在运行时进入函数，该函数将返回秘密。或者，攻击者可以通过执行以下命令来检查移动应用程序与其连接的第三方 API 之间的流量：MitM（中间人） https://blog.approov.io/steal-that-api-key-with-a-man-in-the-middle-attack.
攻击者掌握了秘密，就可以对组织造成很大的损害。损害可能是金钱、声誉和/或监管方面的。从经济上来说，攻击者可以使用提取的秘密来访问您的云提供商以及您名下的按调用付费的第三方 API，从而给您带来额外的成本。此外，您可能会因数据泄露而遭受经济损失，这些数据可能会出售给您的竞争对手或用于实施欺诈。当攻击者使用提取的秘密在社交网络上代表您发布信息时，您的声誉可能会受到影响，从而造成公共关系噩梦。当攻击者使用第三方 API 并违反其条款和条件（例如，频繁使用 API 触发速率限制）时，可能会发生另一种声誉损害，从而导致您无法使用该服务，从而给最终用户带来痛苦。最后但并非最不重要的一点是，当提取的机密是保护第三方 API 访问机密信息的唯一机制时，会引起监管问题。如果攻击者可以检索个人身份信息 (PII) 等机密信息，您的企业可能会因违反欧洲 GDPR 或加利福尼亚州新 CCPA 数据隐私法而被处以监管罚款。
因此，最重要的信息是，从您发布应用程序或将代码推送到公共存储库的那一刻起，您在代码中传递的任何秘密都必须被视为公开。到目前为止，应该清楚的是，最好的方法是完全避免从移动应用程序内访问第三方 API；相反，您应该始终将此访问权限委托给您可以信任和控制的后端，例如反向代理。
您现在可能会说问题刚刚从移动应用程序转移到反向代理或后端服务器，这是一件积极的事情，因为后端或反向代理在您的控制之下，但移动应用程序超出了您的控制范围，因为它位于客户端，因此攻击者可以用它做任何他想做的事。
在后端或反向代理中，您不会向公众公开访问第三方服务的秘密，并且攻击者想要代表您对该第三方服务进行的任何滥用都需要通过您控制的位置，因此您可以应用尽可能多的防御机制，并且这是法律针对您的用例所要求的。
深度安全
将代码放入本机 C++ 代码 (NDK)
当在本机 C 代码中隐藏秘密时，通过静态二进制分析很难找到它，至少对于脚本小子和季节性黑客来说，它需要大多数人可能不具备的更好的技能，因此我强烈建议您将其用作额外的安全层，但为了保护访问您自己的服务的秘密，而不是像我之前提到的第三方服务。
如果您真的决定听从我的建议，并将您的努力转移到您可以控制的地方（例如您自己的后端），那么我建议您阅读我的答案 https://stackoverflow.com/questions/60559419/how-to-secure-an-api-rest-for-mobile-app-if-sniffing-requests-gives-you-the-k/60605789#60605789对这个问题如何保护移动应用程序的 API REST 安全？对于以下部分保护 API 服务器的安全 and 一个可能更好的解决方案。
如果您阅读了上述答案，那么您已经意识到，如果您在后端保留对第三方服务的访问权限，则可以通过使用移动应用程序证明概念，以非常高的置信度将 API 服务器锁定到您的移动应用程序。
您想加倍努力吗？
我看到您消息灵通，因此您已经知道我要分享的内容，但在我对安全问题的任何回复中，我总是喜欢参考 OWASP 基金会的出色工作，因此如果您允许，我会这样做到这里:)
对于移动应用程序
OWASP 移动安全项目 - 十大风险 https://www.owasp.org/index.php/OWASP_Mobile_Security_Project#Top_Ten_Mobile_Risks
OWASP 移动安全项目是一个集中资源，旨在为开发人员和安全团队提供构建和维护安全移动应用程序所需的资源。通过该项目，我们的目标是对移动安全风险进行分类并提供开发控制以减少其影响或被利用的可能性。
OWASP - 移动安全测试指南 https://github.com/OWASP/owasp-mstg:
移动安全测试指南 (MSTG) 是移动应用安全开发、测试和逆向工程的综合手册。
For APIS
OWASP API 安全性前 10 名 https://github.com/OWASP/API-Security
OWASP API 安全项目旨在通过强调不安全 API 的潜在风险并说明如何减轻这些风险，为软件开发人员和安全评估人员提供价值。为了实现这一目标，OWASP API 安全项目将创建并维护十大 API 安全风险文档，以及创建或评估 API 时最佳实践的文档门户。
