Firebase 安全性檢查清單

為確保 Firebase 資源和使用者資料安全無虞，請遵守下列規範。並非所有項目都一定適用於您的需求，但開發應用程式時，請將這些項目納入考量。

避免濫用流量

設定後端服務的監控和快訊

如要偵測阻斷服務 (DOS) 攻擊等濫用流量，請為 Cloud Firestore、Realtime Database、Cloud Storage 和 Hosting 設定監控和快訊。

如果懷疑應用程式遭到攻擊，請盡快與支援團隊聯絡，告知他們目前情況。

啟用 App Check

為確保只有您的應用程式可以存取後端服務，請為支援這項功能的每項服務啟用 Firebase App Check。

設定 Cloud Functions，以因應正常流量進行資源調度

Cloud Functions 會自動調度資源以符合應用程式的需求，但如果發生攻擊事件，這可能代表您會收到巨額帳單。如要避免這種情況，您可以根據應用程式的正常流量，限制函式的並行執行個體數量。

設定快訊，在接近上限時接收通知

如果服務出現要求尖峰，配額通常會啟動，並自動節流應用程式的流量。請務必監控「用量和帳單」資訊主頁，您也可以在專案中設定預算快訊，在資源用量超出預期時收到通知。

避免自我 DOS 攻擊：使用模擬器在本機測試函式

開發 Cloud Functions 時，很容易不小心對自己發動 DOS 攻擊，例如建立無限觸發寫入迴圈。您可以透過 Firebase Local Emulator Suite 進行開發，避免這些錯誤影響即時服務。

如果不小心對自己發動 DOS 攻擊，請從 index.js 刪除函式，然後執行 firebase deploy --only functions，即可取消部署函式。

如果即時回應能力較不重要，請以防禦性方式建構函式

如果不需要即時呈現函式結果，可以批次處理結果，藉此防範濫用流量：將結果發布至 Pub/Sub 主題，並使用排程函式定期處理結果。

瞭解 API 金鑰

Firebase 服務的 API 金鑰並非機密資訊

Firebase 服務的 API 金鑰只會向這些服務識別您的 Firebase 專案和應用程式。授權是透過 Google Cloud IAM 權限、Firebase Security Rules 和 Firebase App Check 處理。

所有 Firebase 佈建的 API 金鑰都會自動限定只能用於 Firebase 相關 API。如果應用程式的設定遵循本頁面的指南，則僅限 Firebase 服務使用的 API 金鑰不需視為密鑰，可安全地納入程式碼或設定檔。

設定 API 金鑰限制

如果您將 API 金鑰用於其他 Google 服務，請務必套用 API 金鑰限制，將 API 金鑰的範圍限定在應用程式用戶端和您使用的 API。

請只將 Firebase 佈建的 API 金鑰用於Firebase 相關 API。如果應用程式使用任何其他 API (例如 Maps 的 Places API 或 Gemini Developer API)，請使用不同的 API 金鑰，並將其限制為適用 API。

妥善保管FCM伺服器金鑰

與 Firebase 服務的 API 金鑰不同，FCM伺服器金鑰 (由舊版 FCM HTTP API 使用)屬於機密資訊，請務必妥善保管。

確保服務帳戶金鑰安全無虞

與 Firebase 服務的 API 金鑰不同，服務帳戶私密金鑰 (由 Firebase Admin SDK 使用) 是機密資訊，必須妥善保管。

Firebase Security Rules

在正式版或鎖定模式中初始化規則

設定 Cloud Firestore、Realtime Database 和 Cloud Storage 時，請初始化 Firebase Security Rules，預設拒絕所有存取權，並在開發應用程式時新增規則，授予特定資源的存取權。

針對 Cloud Firestore (生產模式) 和 Realtime Database (鎖定模式) 的新例項，使用其中一個預設設定。如要使用 Cloud Storage，請先設定安全性規則，如下所示：

rules_version = '2';
service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read, write: if false;
    }
  }
}

安全規則是結構定義，新增文件時請新增規則

請勿在撰寫應用程式後，才撰寫安全性規則，當成是發布前的某項工作。請在撰寫應用程式時一併撰寫安全規則，並將規則視為資料庫結構定義：每當需要使用新的文件類型或路徑結構時，請先撰寫安全規則。

使用 Local Emulator Suite 進行單元測試安全性規則；將其新增至 CI

為確保安全性規則能跟上應用程式的開發進度，請使用 Firebase Local Emulator Suite 進行單元測試，並將這些測試新增至 CI 管道。請參閱這些指南：Cloud Firestore和 Realtime Database。

驗證

自訂驗證：從受信任的 (伺服器端) 環境鑄造 JWT

如果您已有安全無虞的登入系統 (無論是自訂系統或第三方服務)，即可使用現有系統向 Firebase 服務進行驗證。從受信任的環境建立自訂 JWT，然後將權杖傳遞至用戶端，用戶端會使用權杖進行驗證 (iOS+、Android、Web、Unity、C++)。

如要瞭解如何搭配第三方供應商使用自訂驗證，請參閱「使用 Okta 透過 Firebase 驗證」這篇網誌文章。

受管理驗證：OAuth 2.0 供應商最安全

如果您使用 Firebase 的管理式驗證功能，OAuth 2.0 / OpenID Connect 提供者選項 (Google、Facebook 等) 最安全。如果可以，您應支援一或多個這類供應商 (視使用者群而定)。

電子郵件和密碼驗證：為登入端點設定嚴格的配額，防止蠻力攻擊

如果您使用 Firebase 的代管電子郵件/密碼驗證服務，請調高 identitytoolkit.googleapis.com 端點的預設配額，防範暴力攻擊。您可以在 Google Cloud 控制台的「Identity Toolkit API」頁面執行這項操作。

電子郵件地址/密碼驗證：啟用電子郵件列舉防護

如果您使用 Firebase 的電子郵件/密碼管理驗證服務，請啟用電子郵件列舉防護機制，防止惡意行為人濫用專案的驗證端點來猜測帳戶名稱。

升級至 Google Cloud Identity Platform，啟用多重驗證

如要進一步確保登入安全，可以升級至 Google Cloud Identity Platform，新增多重驗證支援功能。升級後，現有的 Firebase Authentication 程式碼仍可繼續運作。

匿名驗證

僅使用匿名驗證進行暖啟動

請只使用匿名驗證，在使用者實際登入前儲存基本狀態。匿名驗證無法取代使用者登入。

如果使用者想在其他裝置上存取資料，請將他們改用其他登入方式

如果使用者清除本機儲存空間或更換裝置，匿名驗證資料將不會保留。如要在單一裝置上保留應用程式重新啟動後的資料，請將使用者轉換為永久帳戶。

使用安全規則，要求使用者轉換為登入供應商，或驗證電子郵件地址

任何人都可以在專案中建立匿名帳戶。因此，請使用安全規則保護所有非公開資料，並要求使用特定登入方法或經過驗證的電子郵件地址。

例如：

allow write: if request.auth.token.firebase.sign_in_provider != "anonymous";
allow write: if request.auth.token.email_verified = true;

Cloud Functions得到安全分

請勿在環境變數中加入私密資訊

在自行代管的 Node.js 應用程式中，您通常會使用環境變數來儲存私密金鑰等私密資訊。請勿在 Cloud Functions 中執行這項操作。由於 Cloud Functions 會在函式叫用之間重複使用環境，因此不應將私密資訊儲存在環境中。

  • 如要儲存 Firebase API 金鑰 (不是密鑰)，只要將其嵌入程式碼即可。

  • 如果您在 Cloud Functions 中使用 Firebase Admin SDK，就不需要明確提供服務帳戶憑證，因為 Admin SDK 可以在初始化期間自動取得憑證。

  • 如果您呼叫需要服務帳戶憑證的 Google 和 Google Cloud API，Node.js 適用的 Google Auth 程式庫可以從應用程式預設憑證取得這些憑證，而這些憑證會自動填入 Cloud Functions。

  • 如要讓Cloud Functions存取非 Google 服務的私密金鑰和憑證，請使用 Secret Manager。

加密私密資訊

如果無法避免將私密資訊傳遞至函式，您必須自行設計自訂解決方案來加密資訊。

簡單函式較安全；如需複雜函式，請考慮使用 Cloud Run

請盡量保持函式簡單易懂。函式中的複雜度通常會導致難以發現的錯誤或非預期行為。

如果需要複雜的邏輯或環境設定，請考慮使用 Cloud Run，而非 Cloud Functions。

環境管理

設定開發和測試專案

為開發、測試和正式環境設定不同的 Firebase 專案。請先針對預先發布專案測試用戶端程式碼，再將其合併至正式環境。

限制團隊存取正式環境資料

如果團隊規模較大，您可以透過預先定義的 IAM 角色或自訂 IAM 角色，限制生產資料的存取權，以減少錯誤和違規行為造成的影響。

如果團隊使用Firebase Local Emulator Suite (建議) 進行開發，您可能不需要授予正式版專案更廣泛的存取權。

媒體庫管理

留意程式庫拼字錯誤或新維護人員

將程式庫新增至專案時，請密切注意程式庫名稱和維護者。與您要安裝的程式庫名稱類似的程式庫可能含有惡意程式碼。

請務必先瞭解變更內容，再更新程式庫

升級前，請先查看所用程式庫的變更記錄。請務必確認升級能帶來價值，並檢查維護人員是否仍是您信任的對象。

將監控程式庫安裝為開發或測試依附元件

使用 Snyk 等程式庫掃描專案，找出不安全的依附元件。

設定 Cloud Functions 的監控功能；在程式庫更新後檢查

如果您使用 Cloud Functions 記錄器 SDK，就能監控異常行為並收到警報，包括程式庫更新造成的行為。