基于Firebase App Check保障移动应用后端安全访问的实践问询

我们的移动应用包含一项需访问后端高成本服务的功能，为保障该服务安全、防范未授权访问，已采用Firebase App Check进行身份验证，当前流程为应用针对每个请求从Firebase App Check获取令牌，后端在允许访问高成本服务前会先验证该令牌。针对提出的三个技术问题，解答如下：

1. 每次请求都获取Firebase App Check令牌是不是最佳实践？会不会影响性能？ #

这绝对不是最佳实践，会带来明显的性能损耗和不必要的开销。

每次调用默认参数为true的getToken()会强制从服务器刷新令牌，都会触发一次额外的网络请求，不仅增加了主业务请求的整体耗时，还会浪费网络资源——尤其是在弱网环境下，这个额外请求的失败概率更高，可能直接导致高成本服务请求失败。

实际上Firebase App Check的SDK已经内置了令牌缓存机制，你只需要调用getToken(false)，就能直接获取本地缓存的有效令牌，无需每次都向服务器发起请求。

2. 要不要在设备上存储令牌并复用？如何平衡安全与效率？ #

不需要自己额外实现令牌存储复用逻辑，Firebase App Check官方SDK已经帮你做好了这件事：

• SDK会自动在本地安全存储令牌，直到令牌快过期时才会自动刷新新的令牌；
• 调用getToken(false)就能直接复用缓存的有效令牌，既减少了网络请求，又保证了效率。

如果非要自己实现存储逻辑，需要注意：

• 安全存储：Android用Keystore、iOS用Keychain，绝对不能明文存在SharedPreferences或UserDefaults这类易被窃取的存储中；
• 有效期校验：每次使用前先检查令牌的过期时间，快过期时主动触发刷新，避免请求时才发现令牌失效。

平衡安全与效率的核心就是：依赖SDK原生的缓存机制，既不用自己处理复杂的安全存储，也能避免不必要的网络请求。

3. 复用令牌会不会引入重放攻击的漏洞？ #

Firebase App Check令牌的核心作用是验证请求来自合法的应用客户端，它本身并不具备防止重放攻击的能力——如果攻击者拿到了有效期内的令牌，确实可以用它发起未授权请求。

要解决这个问题，需要在后端额外补充防护措施：

• 唯一请求ID：给每个请求生成唯一的UUID作为请求标识，后端记录已处理过的请求ID，收到重复ID直接拒绝；
• 时间戳校验：请求中携带当前时间戳，后端验证时间戳与服务器当前时间的差值在合理范围内（比如5分钟），超出范围直接拒绝；
• 结合用户身份验证：如果是敏感的高成本操作，除了App Check令牌，还要同时校验用户的Auth ID Token（比如Firebase Auth的令牌），双重验证应用合法性和用户身份，进一步提升安全性。

优化后的代码示例 #

class 高成本服务实现 extends 高成本服务基类 {
  // 构建请求头，添加Firebase App Check令牌
  Map<String, String> 构建请求头(String appCheck令牌) {
    return {
      'accept': 'application/json',
      'Content-Type': 'application/json',
      'X-Firebase-AppCheck': appCheck令牌,
    };
  }

  @override
  Future<...> 发起高成本请求(...) async {
    try {
      // 传入false，优先使用本地缓存的有效令牌，不强制刷新
      var 令牌 = await FirebaseAppCheck.instance.getToken(false);
      var 请求头 = 构建请求头(令牌!);
      // 后续执行高成本服务请求逻辑...
    } catch (e) {
      // 异常处理逻辑...
    }
  }
}

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