React Native APP 安全怎么做？本地存储、通信与隐私权限

为什么 React Native 的安全问题不能简单套用原生思路

很多团队在开发 React Native 应用时，会下意识地把安全策略照搬自原生 iOS 或 Android 项目。这种做法的风险在于：React Native 的 JavaScript 运行时、异步桥接机制和第三方原生模块的引入，创造了新的攻击面。例如，JS 代码的明文打包、AsyncStorage 的未加密写入、以及原生模块中容易被忽略的日志输出，都可能成为数据泄露的通道。

企业级项目需要意识到，React Native 的安全不是“原生安全 + JS 安全”的简单叠加，而是一个需要从数据生命周期、通信链路和权限管控三个维度重新设计的工程问题。本文围绕这四个核心领域展开：敏感数据的本地存储与加密、网络通信中的证书固定与传输加密、权限申请的时机与最小化原则、以及日志与隐私合规的落地方法。

敏感数据的本地存储：从 AsyncStorage 到 Keychain

默认存储的陷阱

React Native 官方提供的 AsyncStorage 是一个基于 SQLite 的持久化键值存储，数据以明文形式存在于应用的沙盒目录中。在 Android 上，如果设备已 root，任何应用都可以读取该数据库文件；在 iOS 上，虽然沙盒隔离机制更强，但备份到 iCloud 或电脑时，数据同样以明文存在。因此，绝不能用 AsyncStorage 存储用户密码、支付令牌、API Key 或任何个人身份信息。

可用的加密存储方案

对于敏感数据，有两种主流的工程做法：

• **iOS 使用 Keychain Services**：通过原生模块封装，将令牌或密钥存储到系统的安全飞地。这是 iOS 上存储敏感数据的最可靠方式，数据在设备锁定时不可读，且不会随 iCloud 备份。
• **Android 使用 EncryptedSharedPreferences**：同样通过原生桥接，使用 AES-256 加密后存储。或者使用 react-native-keychain 这类封装库，它统一了 iOS 和 Android 的底层安全存储接口。

需要特别说明的是：react-native-keychain 在 iOS 上直接调用 Keychain，在 Android 上依赖 Android Keystore 系统。这个库的维护状态和 API 变化需要以官方 GitHub 仓库为准，建议在项目开始前检查其最新版本是否兼容你的 React Native 版本。

避免“二次存储”风险

一个常见的错误是：从安全接口读取数据后，又将其赋值给 React 组件的 state 或 Redux store。一旦数据进入 JS 层的变量，就可能被 console.log 输出、被第三方库捕获、或被内存快照工具读取。正确的做法是：仅在需要发起网络请求时，通过原生模块临时读取一次，请求完成后立即从 JS 内存中清除引用。

网络通信：证书固定比 HTTPS 本身更重要

HTTPS 只是基础，不是安全

很多团队认为只要 APP 使用 HTTPS 请求，数据就是安全的。实际上，在移动端，中间人攻击的常见手法是安装自签名证书到设备信任链中，然后通过代理工具拦截流量。如果 APP 没有做证书固定，攻击者可以轻松解密所有 HTTPS 流量。

React Native 的 fetch API 和 axios 默认使用系统的 SSL 验证，但系统允许用户添加信任的 CA 证书。对于企业级应用，尤其是涉及金融、支付或敏感个人数据的场景，必须实施证书固定。

证书固定的两种实现方式

• **通过原生网络层实现**：在 iOS 上使用 TrustKit 或 AFNetworking 的 ATS 配置，在 Android 上使用 OkHttp 的 CertificatePinner。这种方式最可靠，因为绕过 JS 层直接操作底层网络栈。
• **通过 JS 层封装**：例如使用 react-native-ssl-pinning 库，在请求时验证服务器的公钥哈希。这种方式开发效率高，但依赖库的维护质量。选择前需要确认该库是否支持最新的 React Native 版本以及是否同时支持 iOS 和 Android。

证书固定的核心是：在 APP 代码中硬编码服务器证书的公钥或证书哈希值，然后在校验时比对。一旦证书过期或更换，APP 需要发布更新。因此，建议在固定证书的同时，留一个备用证书的公钥，以便在证书轮换时保持兼容。

阻止明文传输的配置

在 iOS 的 Info.plist 中，将 NSAppTransportSecurity 设置为要求所有连接使用 HTTPS，并排除允许 HTTP 的例外。在 Android 的 network_security_config.xml 中，同样配置为仅允许加密流量。这两个配置必须在项目初始化时完成，因为后续的 HTTP 请求一旦发出，就失去了控制。

权限申请的时机与最小化原则

权限申请的常见误区

很多 APP 在启动时一次性申请所有权限，包括相机、相册、位置等。这种做法在 iOS 和 Android 上都容易被用户拒绝，并且违反了两大平台的审核指南。更严重的是，申请了不需要的权限，意味着攻击面扩大——一个恶意模块或第三方 SDK 可能利用这些权限获取超出预期的数据。

正确的权限申请策略

• **权限与功能绑定**：只有用户触发某个具体功能时，才申请对应的权限。例如，用户点击“拍照上传”按钮时再申请相机权限，而不是在首页加载时。
• **预先解释原因**：在 iOS 上，系统弹窗只能显示简短的“使用说明”，所以需要在弹窗前先展示一个自定义对话框，说明为什么需要这个权限，以及数据如何使用。这样可以提高用户的授权意愿。
• **拒绝后的降级处理**：如果用户拒绝了权限，APP 不能崩溃或反复弹窗。应该提供手动设置引导，或者使用降级功能（例如没有位置权限时，让用户手动输入地址）。

第三方 SDK 的权限审核

一个经常被忽略的问题是：集成的第三方 SDK（如推送、统计、地图）可能会自行申请权限。在集成前，需要逐一检查 SDK 的清单文件或 Info.plist 配置，确保其不会申请超出业务需求的权限。如果 SDK 强制要求某些权限且无法关闭，建议寻找替代方案。

日志与调试信息的泄露风险

生产环境必须关闭所有日志输出

React Native 开发阶段，开发者习惯使用 console.log 输出变量、网络请求结果和错误信息。这些日志在开发调试时很有用，但一旦发布到生产环境，必须全部移除或禁用。一个真实的案例是：某电商 APP 的 release 包中残留了 console.log，输出中包含用户手机号、订单号和支付流水，导致大量用户数据被第三方日志收集工具抓取。

推荐的做法是：在构建生产包时，通过 babel 插件（如 babel-plugin-transform-remove-console）自动移除所有 console.* 调用。同时，在原生层也要检查是否有原生模块输出了敏感信息，例如网络请求的完整 URL 和参数。

错误上报的脱敏处理

企业级项目通常会集成 Crashlytics 或 Sentry 等错误上报工具。这些工具会收集堆栈信息、设备状态和自定义数据。在配置时，必须设置敏感字段的黑名单，确保上报的数据中不包含 accessToken、password、creditCardNumber 等字段。Sentry 提供了 beforeSend 钩子，可以在数据发送前进行清洗。

隐私合规：GDPR 与国内法规的落地

数据收集的透明性

无论是面向海外市场的 GDPR 还是国内的《个人信息保护法》，都要求 APP 明确告知用户收集了哪些数据、用于什么目的、以及数据存储的位置和期限。在 React Native 应用中，这意味着：

• 在首次启动时展示清晰的隐私政策弹窗，且用户必须主动同意后才能继续使用。
• 如果集成了第三方统计或广告 SDK，需要在隐私政策中列出这些 SDK 的名称、数据收集范围和第三方数据处理方式。
• 提供数据删除和账户注销的入口，且操作必须在后台真正删除数据，而不仅仅是隐藏界面。

数据最小化存储

一个常见的违规行为是：APP 收集了用户的精确位置、通讯录、相册内容等数据，但实际业务只需要城市级别的位置或用户选择的单张照片。在项目设计阶段，就应该明确每个功能所需的最小数据集，并在代码层面限制数据采集范围。例如，使用地理编码只获取城市名，而不是连续上报 GPS 坐标。

跨平台一致的合规处理

React Native 的跨平台特性可能导致 iOS 和 Android 在隐私合规上表现不一致。例如，iOS 14+ 要求 APP 在访问相册前必须获得用户授权，而 Android 的权限模型在不同版本间差异很大。项目团队需要为两个平台分别编写权限申请逻辑，并确保在低版本 Android 设备上也能正确处理权限拒绝。

第三方原生模块的安全评估

依赖库的审查清单

每个引入的第三方原生模块都可能成为安全漏洞的入口。在集成前，建议至少检查以下几点：

• 该模块是否请求了不必要的原生权限？例如，一个图片选择器不应该请求位置权限。
• 该模块是否在日志中输出了敏感数据？可以通过查看其源码中的 NSLog 或 Log.d 调用来判断。
• 该模块是否使用了过时的网络库或加密算法？例如，仍然使用 SSLv3 或 MD5 的模块应该被替换。
• 该模块是否在后台线程中执行了网络请求？这可能导致数据泄露和电池消耗。

维护与更新的风险

很多 React Native 原生模块的维护者只有一两个人，当 React Native 版本升级或 iOS/Android 系统更新时，模块可能无法及时适配。企业项目必须为关键模块（如安全存储、证书固定）准备备选方案，或者自行维护 fork。在 SystemDo 的项目经验中，我们曾遇到过某个加密存储库在 iOS 17 发布后三个月才更新兼容版本，期间项目只能使用自定义的原生封装来替代。

定期安全审计与自动化检查

构建时的安全检查

在 CI/CD 流水线中，可以加入以下自动化检查步骤：

• 使用 npm audit 或 yarn audit 检查依赖库的已知漏洞。
• 使用 react-native-oss-safety 或自定义脚本扫描原生模块的权限声明。
• 在构建生产包后，使用 MobSF 或类似的移动安全框架对 APK/IPA 进行静态分析，检查是否存在未加密的敏感数据、硬编码密钥或不当的网络配置。

上线前的渗透测试

自动化工具无法覆盖所有攻击场景。对于涉及用户支付、医疗健康或金融交易的应用，建议在上线前进行一次专业渗透测试，重点测试以下内容：

• 本地存储的加密强度能否被 root 或越狱设备绕过。
• 中间人攻击是否能在不安装证书的情况下成功。
• 权限申请流程是否存在绕过漏洞，例如通过 deep link 直接触发需要权限的功能。
• 是否存在未声明的网络请求或数据传输。

总结：安全是持续的过程，不是一次性配置

React Native 应用的安全不是通过几个库或几行配置就能一劳永逸的。它需要项目团队在架构设计阶段就纳入考量，并在开发、测试和运维的每个环节持续关注。从本地存储的加密选择，到网络通信的证书固定，再到权限申请的时机控制，每一个决策都直接影响用户数据的保护程度。

对于企业级项目，建议在技术选型阶段就制定一份安全基线文档，明确哪些数据必须加密存储、哪些网络请求必须做证书固定、以及哪些第三方模块不允许引入。同时，保持对操作系统版本更新和隐私法规变化的跟踪，定期审视和更新安全策略。只有这样，React Native 应用才能在快速迭代的业务需求与日益严格的安全合规要求之间找到平衡。