您的问题
我们希望使用来自 api 的数据来验证传递给智能合约的相同数据的正确性，该智能合约对它们进行比较和评估。
祝贺您花时间了解位于区块链前面的 API 需要防止滥用，以防止区块链摄取不需要的数据。
为 API 辩护并不是一件容易的事，但如果您仔细阅读我将要说的所有内容，我希望到最后您将对 API 和移动安全性有一个新的看法，这将使您能够设计和构建一个强大且安全的解决方案。
谁在请求中与什么在提出请求
-该应用程序是唯一可以向我们的 api 发送数据的应用程序
这是一个很难解决的问题，但并非不可能。要了解为什么您需要首先了解请求中的谁 和请求中的什么 之间的区别，否则您添加的任何安全措施都可能无法按预期保护您的 API。
访问 API 服务器的对象和对象的区别
我写了一系列关于 API 和移动安全的文章，在文章 Why Does Your Mobile App Need An Api Key? 你可以详细阅读 谁 和 what 访问你的API 服务器，但我将在这里提取它的主要内容：
what 是向 API 服务器发出请求的事物。它真的是您的移动应用程序的真实实例，还是机器人、自动脚本或攻击者使用 Postman 之类的工具手动绕过您的 API 服务器？
谁是移动应用的用户，我们可以通过多种方式进行身份验证、授权和识别，例如使用 OpenID Connect 或 OAUTH2 流。
因此，将谁视为您的 API 服务器将能够对数据进行身份验证和授权访问的用户，并将什么视为软件制作代表用户提出该请求。
数据完整性
-通过蓝牙从设备获取数据
- 应用程序应该将数据发送到我们的 api
- 重要的是数据不会以任何方式调整或更改
这也很难解决。在收集数据并将其发送到 API 的过程中，可以通过多种方式篡改数据。
使用检测框架处理数据
-通过蓝牙从设备获取数据
在从设备收集数据时，可以使用检测框架在将数据发送到 API 之前对其进行操作。一个流行的检测框架是Frida：
将您自己的脚本注入黑盒进程。挂钩任何功能、监视加密 API 或跟踪私有应用程序代码，无需源代码。编辑，点击保存，立即查看结果。所有这些都无需编译步骤或程序重新启动。
因此，攻击者会注入一个脚本，在运行时监听收集数据的方法或将数据发送到 API 的方法，然后篡改正在发送的数据。
使用中间人攻击操纵数据
另一种选择是攻击者也可以使用 Frida 执行中间人攻击，以允许像 mitmproxy 这样的工具拦截和修改请求。您可以阅读我的文章How to Bypass Certificate Pinning with Frida on an Android App，了解如何使用 Frida 执行中间人攻击：
今天我将展示如何使用 Frida 检测框架在运行时挂钩到移动应用程序并检测代码以执行成功的中间人攻击，即使移动应用程序已经实现了证书锁定。
绕过证书固定并不太难，只是有点费力，并且允许攻击者详细了解移动应用程序如何与其 API 通信，然后使用相同的知识来自动化攻击或围绕它构建其他服务。
在运行时注入 Frida 脚本允许几乎无限的可能性来篡改您的数据完整性或移动应用在运行时所做的任何事情。
可能的解决方案
安全存储
我已经阅读了很多关于：
iOS - 钥匙串服务和
Android - 密钥库
在 React Native 文档中：https://reactnative.dev/docs/security
建议使用此机制，但您需要注意，存储在安全存储中的任何内容都需要在某些时候被移动应用程序访问和使用，此时攻击者可以使用检测框架在运行时挂钩到移动应用程序代码。例如，在检索安全存储的秘密时，攻击者可以将其提取出来以在移动应用之外使用，从而自动执行 API 请求，就好像它们来自移动应用一样。
因此，使用它可以让技术水平较低的攻击者更难篡改您的移动应用，但请记住，技术水平较高的攻击者可能会找到绕过它的方法。
保护移动应用中的数据完整性
-重要的是不要以任何方式调整或更改数据
为了防止数据在到达 API 服务器之前被篡改，您需要采用一些解决方案，例如 RASP：
运行时应用程序自我保护 (RASP) 是一种安全技术，它使用运行时工具通过利用运行软件内部的信息来检测和阻止计算机攻击。
据说 RASP 技术通过监控其输入并阻止可能允许攻击的输入来提高软件的安全性，同时保护运行时环境免受不必要的更改和篡改。
仅使用 RASP 的问题是 API 服务器无法查看对移动应用程序的持续攻击，因此无法拒绝来自受到攻击的移动应用程序的请求。此外，熟练的攻击者可以使用检测框架绕过 RASP，API 服务器不会意识到这种情况，因此会继续为请求提供服务，因为它没有机制知道 什么 发出的请求确实是您的移动应用的真实且未经篡改的版本。
保护 API 服务器
我建议您阅读this answer 我提出的问题如何保护移动应用程序的 API REST？，尤其是强化和屏蔽移动应用程序部分 ，保护 API 服务器和可能更好的解决方案。
提议的解决方案之一是使用在移动设备外部（例如在云上）运行的移动应用证明解决方案，因此不会对移动应用和设备运行的状态做出客户端决策，相反，它们在云服务中完成并作为签名的 JWT 令牌传输到 API 服务器，然后 API 服务器可以用来验证发出请求的 什么 确实是真实且未篡改的版本的官方移动应用程序。
Android Safetynet 和 iOS Devicecheck
还有 SafeNet(Android) 或 DevieCheck(IOS)（我读过的 react native 文档或文章中从未提及）
使用 Android SafetyNet 和 iOS DeviceCheck 运行时保护无疑是一个很好的起点，但您需要了解它们的范围、限制和复杂性。它们可以与强大的移动应用程序证明解决方案相辅相成，为您提供更高级别的安全性和信心，让您的 API 服务器能够知道何时请求不是来自它所期望的什么、真实且您的移动应用程序的未篡改版本。
安全层
我们应该为我们的用例使用哪些安全层以使 api 最安全，我如何在 react native 中实现它们？
我不会在这里讨论如何在 React 中实现它，因为这是一个很大的话题，确切的代码将取决于你当前的实现，但我会在这里总结关键点。
安全性始终是在您负担得起且符合法律、标准和业务要求的情况下添加尽可能多的层。总而言之，您应该考虑以下主题：
- 不要在您的移动应用代码中硬编码秘密，但如果您真的想这样做，至少使用原生 C 代码。
- 对您的移动应用代码进行模糊处理，因为这会增加对移动应用代码进行逆向工程以使用检测框架的难度。
- 在您的移动应用程序代码中使用运行时保护，并优先考虑那些不在客户端做出决定并允许 API 服务器验证请求确实来自 what 它预计您的移动应用是真实且未经篡改的版本，就像我之前提到的移动应用证明中所述。
- 使用证书固定到公钥来防止中间人攻击，但要知道它可以被绕过。我建议您阅读this answer 中的
Preventing MitM Attacks 部分，我提出了另一个问题，您将在其中学习如何实现静态证书固定。如果可以，请尝试改用动态证书固定，以允许远程更新您的移动应用使用的固定。
- 在您的 API 服务器中，您可以使用速率限制，但不要在标题中返回有关可用速率限制的信息，因为这就像把前门的钥匙放在垫子下面。
- 您可以使用人工智能解决方案，但请注意它们在否定识别模型中工作，并且容易出现误报和误报。如果使用让 API 服务器知道何时受到攻击的移动应用运行时保护，则可以推迟使用 AI 解决方案，直到 API 服务器需要使用其他类型的客户端，例如网络应用。
这不是您可以考虑使用以保护您的移动应用程序和 API 服务器的唯一主题列表，但我认为这些主题对您来说更重要。
您想加倍努力吗？
在回答安全问题时，我总是喜欢参考 OWASP 基金会的出色工作。
对于 APIS
OWASP API Security Top 10
OWASP API 安全项目旨在通过强调不安全 API 中的潜在风险并说明如何降低这些风险，为软件开发人员和安全评估人员提供价值。为了促进实现这一目标，OWASP API 安全项目将创建和维护一份“十大 API 安全风险”文档，以及一个文档门户，用于在创建或评估 API 时提供最佳实践。
对于移动应用
OWASP Mobile Security Project - Top 10 risks
OWASP 移动安全项目是一个集中资源，旨在为开发人员和安全团队提供构建和维护安全移动应用程序所需的资源。通过该项目，我们的目标是对移动安全风险进行分类并提供开发控制以减少其影响或被利用的可能性。
OWASP - Mobile Security Testing Guide:
移动安全测试指南 (MSTG) 是一本用于移动应用安全开发、测试和逆向工程的综合手册。