Firebase App Check：iOS环境下1%-10%未验证请求是否正常？

• 少量未验证请求在TestFlight测试阶段属于正常现象，但Storage的10%占比偏高，需要排查原因；RTDB的1%比例在可接受范围内。

可能的原因分析 #

• TestFlight设备的初始化问题：
  部分测试设备可能因系统版本过低、网络限制（比如防火墙拦截Google服务），或是App首次启动时App Check令牌还未生成完成，就发起了Storage请求，导致未验证。另外TestFlight的Beta版本偶尔会有缓存或初始化顺序的问题，也会引发这类情况。
• 请求触发时机差异：
  Storage通常会在App启动后更早加载资源（比如图片、文件），此时App Check令牌可能还没就绪；而RTDB的请求一般触发较晚，令牌已经生成，所以未验证比例更低。
• 配置细节疏漏：
  确认是否给Storage和RTDB都正确开启了App Check强制验证，有没有可能Storage的安全规则配置宽松，允许了部分未验证请求；另外检查Apple App Attest这类提供者的配置，是否正确关联了TestFlight对应的Bundle ID。

建议的处理步骤 #

• 先通过Firebase控制台的App Check日志，定位未验证请求的具体场景：比如是特定设备、特定操作，还是特定时间段的请求，缩小排查范围。
• 优化App Check令牌的获取时机：在App启动阶段提前初始化App Check，确保令牌就绪后再发起Storage等资源请求，避免冷启动时的未验证请求。
• 检查Storage的安全规则：确认规则里是否加入了request.app != null的验证条件，避免存在allow read, write: if true;这类完全开放的规则。
• 正式发布前再观察数据，如果正式版发布后未验证请求占比仍超过5%，就要重点排查配置或代码逻辑问题。

内容的提问来源于stack exchange，提问作者Julian D.