Firebase 安全性檢查清單

為確保 Firebase 資源和使用者資料安全無虞，請遵循下列規範。並非所有項目都適用於您的需求，但請在開發應用程式時牢記這些項目。

防範濫用流量

設定後端服務的監控和警告功能

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

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

啟用 App Check

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

設定 Cloud Functions，以便根據一般流量調整資源

Cloud Functions 會自動調度資源來滿足應用程式需求，但如果發生攻擊事件，帳單費用可能會非常高。為避免這種情況，您可以根據應用程式的一般流量，限制函式的並行執行個體數量。

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

如果服務的要求量激增，配額通常會生效，並自動限制應用程式的流量。

避免自我阻斷服務：使用模擬器在本機測試函式

開發 Cloud Functions 時，您可能會不小心對自己發動阻斷服務攻擊，例如建立無限的觸發條件寫入迴圈。您可以使用 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 (例如 Places API for Maps 或 Gemini Developer API)，請使用獨立 API 金鑰，並限制該金鑰只能用於適用的 API。

保密FCM伺服器金鑰

與 Firebase 服務的 API 金鑰不同，FCM 伺服器金鑰 (由舊版 FCM HTTP API 使用) 是機密資訊，必須保密。

啟用 Cloud Messaging 的稽核記錄

建議為 Cloud Messaging 啟用 Cloud 稽核記錄，以便記錄 FCM 資源中的管理活動和存取事件。

確保服務帳戶金鑰不外洩

與 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。

  • 如要將非 Google 服務的私密金鑰和憑證提供給Cloud Functions，請使用 Secret Manager。

加密私密資訊

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

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

請盡量讓函式保持基本且易於理解。函式中的複雜度通常會導致難以發現的錯誤或非預期行為。

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

環境管理

設定開發和測試專案

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

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

如果您與較大的團隊合作，可以使用預先定義的 IAM 角色或自訂 IAM 角色限制正式環境資料的存取權，降低錯誤和侵害行為造成的後果。

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

媒體庫管理

留意程式庫名稱是否拼寫錯誤，或是否有新的維護者

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

請勿在不瞭解變更的情況下更新程式庫

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

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

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

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

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