本文目錄

自 2026 年 11 月 2 日起，Firebase 可在專案中為 Firebase AI Logic 自動強制啟用 App Check（若尚未強制）。依 2026 年 10 月 27 日 Firebase 發布記錄，目的是在經 Firebase AI Logic 存取 Gemini API 時加強防護。未攜帶有效 App Check 權杖的請求會被攔截，範圍包括尚未接入生產環境 attestation 的已發布應用——不只是本地未完成的構建。

這是該時間窗下的遷移與排障清單：確認呼叫路徑 → 判斷是否需要臨時延後 → 接入生產 attestation → 觀察請求／App Check 指標 → 啟用或確認強制。範圍始終是 Firebase AI Logic，不是所有 Gemini API 呼叫。不經 Firebase AI Logic 的直連 Gemini API 流量是另一條面，不是這次 11 月 2 日自動強制通知所針對的對象。

各專案何時真正開始強制，以該專案 Firebase 控制台 Security > App Check 頁面與即時請求指標為準。僅供參考。

計劃生效日改了什麼

Firebase 2026 年 10 月 27 日發布記錄寫明：自 2026 年 11 月 2 日起可為 Firebase AI Logic 自動強制 App Check；若仍有未接 App Check 的已發布版本，可臨時延後自動強制。Firebase AI Logic FAQ 重複同一日曆，並給出硬截止：過了 2027 年 1 月 21 日，就不能再為 Firebase AI Logic 延後自動強制。

官方表述沒有公佈具體 UTC 小時或具名時區。把「11 月 2 日」讀作日曆日期，比自行假定午夜截止更穩妥。

強制開啟後，FAQ 的失敗模式很直接：任何發往 Firebase AI Logic、卻沒有有效 App Check 權杖的請求都會被擋，包括從未實現生產 attestation 提供方的已發布版本。因此會出現「開發環境仍可用 debug 權杖，商店包卻呼叫失敗」的分裂——正是許多團隊描述的現象。

步驟 1 — 確認呼叫路徑是 Firebase AI Logic

改強制日期之前，先確認失敗流量確實走 Firebase AI Logic 客戶端 SDK／Firebase AI Logic 路徑，而不是從不經過該產品 App Check 的後端裸調 Gemini Developer API 或 Agent Platform Gemini API。

可檢查：

  • 客戶端初始化走 Firebase AI Logic SDK 入口（按平臺：移動端、Web、Flutter、Unity 等），而不是完全繞開 App Check 的純服務端 Gemini 客戶端。
  • 專案已啟用 Firebase AI Logic，失敗面是經該產品存取 Gemini 的應用。
  • 出錯時間與 Security > App Check > APIs 中 AI Logic 一行的強制狀態相符，而不是無關的 API 金鑰、配額或模型名 404。

若呼叫根本不經 Firebase AI Logic，這份 11 月 2 日 App Check 自動強制說明就應按那條路徑自己的文件排查，而不是照這份 App Check 清單做。

站內相關（Gemini API 請求預設儲存變更，與 App Check 不同題）：Gemini API 新付費專案預設儲存 Generate Content 請求。

步驟 2 — 臨時延後只作遷移緩衝

若終端使用者仍停留在未接 App Check 的版本，Firebase 允許臨時延後自動強制：

  1. 打開 Firebase 控制台。
  2. 進入 Security > App Check > APIs。
  3. 找到 Firebase AI Logic 一行。
  4. 使用行末 Enforces 日期選擇器（編輯控制項）。
  5. 選擇不晚於 2027 年 1 月 21 日的強制日期並儲存。

FAQ 寫明：2027 年 1 月 21 日是可選最晚日期；過後再也不能為 Firebase AI Logic 延後自動強制。

延後不是長期「關掉驗證」教程。延後且未強制期間，官方文件警告：Gemini API 存取仍易受濫用。緩衝用來上線 attestation、遷移使用者，然後再打開強制（或等到所選日期生效）。日期選擇器不是永久關閉開關。

步驟 3 — 按平臺接入生產 attestation

對已發布應用，FAQ 的遷移順序是：需要則先延後 → 儘快實現生產 attestation 提供方 → 監控請求 → 再強制。該 FAQ 列出的提供方：

平臺生產 attestation 提供方（文件所列）
Apple 平臺DeviceCheck、App Attest 或 reCAPTCHA Enterprise
AndroidPlay Integrity 或 reCAPTCHA Enterprise
WebreCAPTCHA Enterprise
Flutter支援以上提供方，含 reCAPTCHA Enterprise
Unity支援以上提供方（FAQ 寫 reCAPTCHA Enterprise 即將支援）

按出貨平臺實現對應提供方，遵循該棧當前的 App Check 接入說明，並發布新版本，讓使用者離開未 attestation 的二進位。FAQ 還提到：接入時啟用 limited-use tokens，可為日後的 replay protection（一次性權杖）留口——這是可選增強，不能代替基線強制。

文件未列出的 attestation 廠商不在該 FAQ 平臺矩陣內。

步驟 4 — 觀察請求與 App Check 指標再談「可以強制」

attestation 上線後，持續看流量，直到近期請求幾乎都來自已驗證客戶端。FAQ 的決策口徑是定性的：當幾乎所有近期請求都來自 verified 客戶端時，再強制更穩妥。以該專案 Firebase 控制台的 App Check／請求視圖為準；單臺裝置測試不足以下結論。

宜對齊的訊號：

  • Firebase AI Logic 上 verified 與 unverified 請求佔比。
  • 舊商店包是否仍產生 unverified 量。
  • 已 attestation 版本的分階段放量是否在替換未 attestation 人群。

數字看起來健康之後，才適合把強制視為對該使用者群「可保持開啟」。

步驟 5 — 啟用或確認強制

若 Firebase AI Logic 的 App Check 尚未強制，在 attestation 覆蓋可接受後啟用。若 Firebase 已在 11 月 2 日及之後自動強制（且未設延後），在 APIs 頁確認 Enforces 狀態並繼續監控。

FAQ 提醒：若到計劃日仍未強制且未配置延後，Firebase 可自動強制。沒有延後計劃卻乾等，等於讓「已發布但未 attestation」的使用者被擋。

保持強制時的本地開發

強制不必為本地開發而關掉。FAQ 寫明：Firebase AI Logic 已強制 App Check 時，本地可用 App Check debug provider，同時保持對該產品的強制。這樣生產側保護仍在，開發機可用 debug 權杖——優於僅為跑模擬器就把整個專案停在開放延後上。

清單（短版）

  1. 確認失敗呼叫走 Firebase AI Logic（不是無關 Gemini 路徑）。
  2. 若舊版未 attestation 仍在線，僅將 Enforces 臨時延至不晚於 2027 年 1 月 21 日作緩衝。
  3. 按 Apple／Android／Web／Flutter／Unity 接入文件所列生產 attestation；發版並遷移使用者。
  4. 監控 verified／unverified 指標至覆蓋可接受。
  5. 啟用或確認 Firebase AI Logic 的 App Check 強制；本地用 debug provider，強制保持開啟。
  6. 延後不是永久關閉——關閉強制期間濫用風險仍在。

範圍說明

範圍仍是 Firebase AI Logic，不是網際網路上每一條 Gemini API。延後只作遷移緩衝，過了允許視窗也不能長期關閉 App Check。官方沒有公佈強制翻轉的 UTC 小時；控制台文案若有變動，以 Firebase 發布記錄與 Firebase AI Logic App Check FAQ 為準。

在該計劃自動強制視窗裡，操作問題很簡單：客戶端路徑是不是 Firebase AI Logic，每個出貨平臺是否用文件所列生產 attestation 提供方出示有效 App Check 權杖，以及 Security > App Check 上的強制狀態與指標是否符合預期。