React Native应用源码安全与后端请求合法性校验方案咨询

开发者阿泽

2026-8-15

核心问题拆解与实践建议

一、验证请求来源：防止第三方工具调用接口

你的核心需求是确保后端只接受自家APP的请求，先明确几个方案的实际作用和不足：

客户端固定密钥：这个思路有缺陷——哪怕做了代码混淆，APK反编译后仍有概率提取到密钥（尤其是静态存储的）。如果要用，别用固定密钥，改成动态签名机制：服务器给每个合法会话下发临时非对称密钥对的私钥，客户端每次请求用私钥对请求参数+时间戳签名，后端用公钥验签，同时校验时间戳的时效性（比如5分钟内有效）。但私钥存在客户端仍有风险，建议结合设备指纹（比如IMEI、Android ID，注意隐私合规）+ 当前会话Token生成签名，增加伪造难度。
SSL Pinning：它的作用是防止中间人攻击，确保请求确实发送到你的服务器，而不是恶意代理，但不能验证请求是否来自你的APP，别搞混它的定位。
补充校验：后端可以加一些隐蔽的上下文校验，比如：
- 校验请求参数里的某个前端动态生成的标识（比如页面加载时生成的随机串，和会话绑定）；
- 限制请求的时序（比如注册请求必须先触发页面初始化请求，无前置请求直接拒绝）；
- 对User-Agent做基础校验（虽然能伪造，但可以过滤掉明显异常的）。

代码混淆在EAS Build中的实现：
Android端：在eas.json的build配置里，开启proguard，可自定义proguard-rules.pro规则，示例配置：
```
{
  "build": {
    "production": {
      "android": {
        "buildType": "app-bundle",
        "proguard": true,
        "proguardRules": "proguard-rules.pro"
      }
    }
  }
}
```
iOS端：Expo的EAS Build支持开启代码混淆，在eas.json里配置ios.obfuscationEnabled: true即可。
仅靠混淆不够：混淆只能增加反编译后的阅读难度，无法阻止篡改。还要加：
- 应用加固：Android用第三方加固工具（如360加固、腾讯加固），iOS可以利用App Store的官方保护，或者第三方合规加固工具（注意苹果的审核规则）；
- 完整性校验：客户端启动时，计算自身APK/IPA的签名哈希，和服务器存储的合法哈希对比，不一致就强制退出，防止篡改后的包运行。

Expo Secure Store：比普通的SharedPreferences/Keychain安全，但在root/jailbreak设备上仍有被读取的风险，结合JailMonkey检测是基础操作，但要注意：
- JailMonkey的检测可以被绕过（比如Xposed模块、修改系统文件），所以不能完全依赖，发现root/jailbreak后，应该限制核心功能（比如禁止注册/登录），而不是只做提示；
- 敏感信息尽量不要在客户端长期存储，比如临时密钥用完就删除，核心认证用服务器下发的短期Token。

你的方案是基础的安全框架，但还有几个关键漏洞要补：

客户端密钥泄露风险：哪怕存在Secure Store，root设备可以通过内存dump获取，所以尽量把敏感逻辑放在后端，客户端只做交互，比如不要在客户端处理加密核心逻辑，明文参数走HTTPS+SSL Pinning传输，后端负责加密存储。
模拟请求的绕过：如果攻击者拿到了签名规则，还是能模拟请求，所以要结合业务逻辑防护，比如注册时必须验证短信/邮箱验证码，登录时加滑动验证码，增加攻击成本。
异常请求检测：后端要做流量分析，比如同一个IP短时间内大量注册请求、参数格式异常，直接拉黑IP或触发人机验证。
动态密钥轮换：服务器定期给合法客户端下发新的临时签名密钥，避免单个密钥泄露后被长期滥用。

移动应用安全没有绝对的“万能方案”，核心是多层防护，提高攻击成本。你的现有方案覆盖了基础层面，但需要补充动态签名、应用加固、业务逻辑校验这些环节，才能有效降低被攻击的风险。

内容的提问来源于stack exchange，提问作者Bassel Turky