深色模式
请求合法性验证
什么是 Firebase App Check？
App Check 的核心作用是保护你的后端服务（包括 Firebase Authentication、Cloud Functions、Firestore 等），确保只有你的正版、未被篡改的应用才能访问这些服务。它通过验证请求是否来自你的真实应用和真实的、未被篡改的设备来实现这一点。
这和“工作量证明”的目标是一致的：增加攻击者的成本，过滤掉非法的客户端请求。
App Check 是如何工作的？
App Check 使用平台特定的“证明提供者”来验证客户端：
- Android: 使用 Play Integrity API。
- iOS: 使用 DeviceCheck 或 App Attest。
- Web: 使用 reCAPTCHA v3 或 reCAPTCHA Enterprise。
对于 Flutter 项目，firebase_app_check 插件已经封装好了对 Android 和 iOS 平台的支持。
为什么移动端不使用 reCAPTCHA
核心原因在于 Web 和移动端（iOS/Android）在平台特性和安全模型上存在根本性的差异。
Firebase App Check 的目标是验证请求的来源是否合法，它会为不同平台选择最适合、最可靠的验证工具。
Web 端：开放与匿名
在 Web 环境中，你服务器的所有请求都来自用户的浏览器。
- 代码开放：你的前端代码（JavaScript, HTML）对所有用户都是公开的，任何人都可以查看、复制甚至修改。
- 环境不可信：攻击者可以轻易地使用脚本（如 cURL）、无头浏览器（Headless Chrome）或者自动化工具来模拟一个真实的用户浏览器环境，然后直接调用你的 API 接口。
在这种情况下，我们很难去验证“运行在我服务器上的代码，是否真的是我写的那份未被修改的前端代码”。因为代码本身是开放的，无法作为信任的依据。
因此，Web 安全的重点就变成了验证“操作者是不是一个真实的人类”。而这正是 reCAPTCHA 的专长。它通过分析用户的鼠标移动、点击、键盘输入、浏览器指纹等一系列行为，来判断当前操作是来自一个真人还是一个自动化脚本（Bot）。
Web 端的核心问题是：我如何区分“人”和“机器”？ reCAPTCHA 就是答案。
移动端的优势：封闭与可信
移动端 App 则完全不同。
- 代码封闭：App 是被编译成二进制文件的（Android 的 APK/AAB, iOS 的 IPA），并且有开发者的数字签名。分发渠道（Google Play, Apple App Store）也会对 App 进行审核和再次签名。
- 环境可信：操作系统（Android/iOS）本身提供了强大的安全沙箱和硬件级别的安全保障（如 iOS 的 Secure Enclave，Android 的硬件支持证明）。
在这种环境下，我们可以做到比“识别人与机器”更强大、更可靠的事情：验证“App 和设备的真实性”。
在 Android 上 (Play Integrity): Google Play 服务可以检查：
- App 真实性：这个请求是不是来自从 Google Play 下载的、拥有正确签名的、未被篡改的你的 App？
- 设备真实性：这个设备是不是一台经过 Google 认证的、没有被 Root 或破解的真实 Android 设备？
在 iOS 上 (App Attest): Apple 可以利用设备的安全芯片（Secure Enclave）生成加密证明，来证实：
- 这个请求确实是由你的、拥有合法签名的 App 在一台真实的苹果设备上发出的。
移动端的核心问题是：这个请求是不是来自“我那个正版的、未被篡改的 App”，并且运行在“一台真实的、安全的设备”上？ Play Integrity 和 App Attest 就是答案。
总结对比
| 特性 | Web 端 (reCAPTCHA) | 移动端 (Play Integrity / App Attest) |
|---|---|---|
| 验证目标 | 操作者的行为 | App 和设备的身份 |
| 验证方式 | 行为分析，人机挑战 | 数字签名，硬件加密证明 |
| 回答的问题 | “这是真人在操作吗？” | “这是我的正版 App 在正版设备上发出的请求吗？” |
| 安全性 | 相对较低（可被高级机器人模拟） | 非常高（依赖于操作系统和硬件安全） |
综上所述，因为移动端平台提供了验证 App 和设备本身真实性的强大能力，所以 App Check 自然会选择使用这些原生、更安全的方式，而没有必要再使用 reCAPTCHA 这种退而求其次的方案了。而在开放的 Web 平台，reCAPTCHA 已经是区分人机、防止滥用的最佳实践方案。