如要確保 Firebase 資源和使用者資料的安全，請遵循下列規範。並非每項項目都適用於您的需求，但在開發應用程式時請務必加以考量。
避免濫用流量
設定後端服務的監控和快訊功能
如要偵測濫用流量 (例如阻斷服務 (DoS) 攻擊)，請為 Cloud Firestore、Realtime Database、Cloud Storage 和 Hosting 設定監控和快訊功能
如果您懷疑應用程式遭到攻擊，請盡快與支援團隊聯絡，讓他們瞭解發生的情況。
啟用 App Check
為確保只有您的應用程式可以存取後端服務，請為每項支援 Firebase App Check 的服務啟用此功能。
設定 Cloud Functions 以便在正常流量下擴充
Cloud Functions 會自動調度資源以符合應用程式的需求，但在遭到攻擊時，這可能會產生高額帳單。如要避免這種情況，您可以根據應用程式的一般流量，限制函式並行的執行個體數量。
設定快訊，在即將達到限制時接收通知
如果您的服務出現大量要求，系統通常會啟用配額，並自動限制應用程式的流量。請務必監控用量和帳單資訊主頁，但您也可以為專案設定預算快訊，在資源用量超出預期時收到通知。
避免自我拒絕服務攻擊：使用模擬器在本機測試函式
在開發 Cloud Functions 時，很容易不小心造成自己遭受 DOS 攻擊，例如建立無限觸發寫入迴圈。您可以使用 Firebase Local Emulator Suite 進行開發，避免這些錯誤影響到即時服務。
如果您不小心對自己進行拒絕服務攻擊，請從 index.js 中刪除函式，然後執行 firebase deploy --only functions
如果即時回應速度不太重要，請採用防禦性結構
如果您不需要即時顯示函式的結果，可以透過批次處理結果來減輕惡意流量：將結果發布至 Pub/Sub 主題，並使用排程函式定期處理結果。
瞭解 API 金鑰
Firebase 服務的 API 金鑰並非機密資訊
Firebase 只會使用 API 金鑰向 Firebase 服務識別應用程式的 Firebase 專案，而不會用於控制資料庫或 Cloud Storage 資料的存取權，這項作業會使用 Firebase Security Rules 執行。因此，您不必將 Firebase 服務的 API 金鑰視為密碼，而且可以安全地將這些金鑰嵌入用戶端程式碼中。進一步瞭解 Firebase 的 API 金鑰。
設定 API 金鑰限制
為進一步防止攻擊者嘗試使用 API 金鑰來偽造要求，您可以新增 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、網頁版、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，就可以監控並接收異常行為的警示，包括因程式庫更新而導致的行為。