為確保您的 Firebase 資源和用戶數據的安全，請遵循這些準則。並非每個項目都一定適用於您的要求，但在您開發應用程序時請記住它們。
避免濫用交通
為後端服務設置監控和警報
要檢測濫用流量，例如拒絕服務 (DOS) 攻擊，請為Cloud Firestore 、實時數據庫、 Cloud Storage和託管設置監控和警報
如果您懷疑您的應用程序受到攻擊，請盡快聯繫支持人員，讓他們知道發生了什麼。
啟用應用檢查
為幫助確保只有您的應用程序可以訪問您的後端服務，請為支持它的每個服務啟用App Check 。
配置您的 Cloud Functions 以針對正常流量進行擴展
Cloud Functions 會自動擴展以滿足您應用程序的需求，但如果發生攻擊，這可能意味著一筆巨額費用。為防止這種情況，您可以根據應用的正常流量限制函數的並發實例數。
設置警報以在接近達到限制時收到通知
如果您的服務有請求高峰，配額通常會啟動，並自動限制您的應用程序的流量。確保監控您的使用情況和計費儀表板，但您也可以在您的項目上設置預算警報，以便在資源使用超出預期時收到通知。
防止自我 DOS：使用模擬器在本地測試功能
在開發 Cloud Functions 時很容易不小心 DOS 自己：例如，通過創建無限觸發寫入循環。您可以通過使用Firebase 模擬器套件進行開發來防止這些錯誤影響實時服務。
（如果你自己不小心做了 DOS，通過從index.js中刪除它然後運行
在實時響應不太重要的地方，結構起到防禦作用
如果您不需要實時呈現函數的結果，您可以通過批量處理結果來減輕濫用流量：將結果發佈到Pub/Sub主題，並使用預定函數定期處理結果.
了解 API 密鑰
Firebase 服務的 API 密鑰不是秘密
Firebase 僅使用 API 密鑰來向 Firebase 服務識別您應用的 Firebase 項目，而不是控制對數據庫或云存儲數據的訪問，這是使用Firebase 安全規則完成的。因此，您無需將 Firebase 服務的 API 密鑰視為機密，您可以安全地將它們嵌入到客戶端代碼中。詳細了解Firebase 的 API 密鑰。
設置 API 密鑰範圍
作為對試圖使用您的 API 密鑰欺騙請求的攻擊者的額外威懾，您可以創建適用於您的應用程序客戶端的API 密鑰。
對 FCM 服務器密鑰保密
與 Firebase 服務的 API 密鑰不同，FCM 服務器密鑰（由舊版 FCM HTTP API 使用）是敏感的，必須保密。
對服務帳戶密鑰保密
與 Firebase 服務的 API 密鑰不同的是，服務帳戶私鑰（由Admin SDK使用）是敏感的，必須保密。
安全規則
在生產或鎖定模式下初始化規則
當您設置 Cloud Firestore、Realtime Database 和 Cloud Storage 時，初始化您的安全規則以默認拒絕所有訪問，並添加規則以在您開發應用時授予對特定資源的訪問權限。
這是 Cloud Firestore（生產模式）和實時數據庫（鎖定模式）新實例的默認設置之一。設置新數據庫實例時選擇此選項。
對於 Cloud Storage，從如下安全規則配置開始：
rules_version = '2';
service firebase.storage {
match /b/{bucket}/o {
match /{allPaths=**} {
allow read, write: if false;
}
}
}
安全規則是一種模式；添加文檔時添加規則
不要在編寫應用程序後編寫安全規則，作為一種啟動前任務。相反，在編寫應用程序時編寫安全規則，將它們視為數據庫模式：每當您需要使用新的文檔類型或路徑結構時，首先編寫其安全規則。
使用 Emulator Suite 進行單元測試安全規則；將其添加到 CI
為確保您的安全規則與應用的開發保持同步，請使用Firebase 模擬器套件對您的規則進行單元測試，並將這些測試添加到您的 CI 管道中。請參閱這些Cloud Firestore和實時數據庫指南。
驗證
自定義身份驗證：從受信任的（服務器端）環境中創建 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 Console 中的 API 頁面執行此操作。
電子郵件密碼身份驗證：啟用電子郵件枚舉保護
如果您使用 Firebase 的託管電子郵件密碼身份驗證服務，請啟用電子郵件枚舉保護，以防止惡意行為者濫用您項目的身份驗證端點來猜測帳戶名稱。
升級到 Cloud Identity Platform 以進行多重身份驗證
為了提高登錄時的安全性，您可以通過升級到Cloud Identity Platform添加多重身份驗證支持。升級後，您現有的 Firebase 身份驗證代碼將繼續工作。
匿名認證
僅使用匿名身份驗證進行熱入職
僅在用戶實際登錄前使用匿名身份驗證為用戶保存基本狀態。匿名身份驗證不能替代用戶登錄。
如果用戶在丟失手機時需要數據，請將他們轉換為另一種登錄方法
如果用戶清除本地存儲或切換設備，匿名身份驗證數據將不會保留。如果您需要在單個設備上重啟應用程序後保留數據，請將用戶轉換為永久帳戶。
使用要求用戶轉換為登錄提供商或驗證其電子郵件的安全規則
任何人都可以在您的項目中創建匿名帳戶。考慮到這一點，使用需要特定登錄方法或經過驗證的電子郵件地址的安全規則來保護所有非公開數據。
例如：
allow write: if request.auth.token.firebase.sign_in_provider != "anonymous";
allow write: if request.auth.token.email_verified = true;
環境管理
設置開發和暫存項目
為開發、暫存和生產設置單獨的 Firebase 項目。在針對暫存項目進行測試之前，不要將客戶端代碼合併到生產環境中。
限制團隊訪問生產數據
如果您與更大的團隊合作，您可以通過使用預定義角色或自定義 IAM 角色限制對生產數據的訪問來減輕錯誤和違規的後果。
如果您的團隊使用模擬器套件進行開發，您可能不需要授予對生產項目的更廣泛訪問權限。
圖書館管理
當心圖書館的拼寫錯誤或新的維護者
將庫添加到項目時，請密切注意庫的名稱及其維護者。與您打算安裝的庫同名的庫可能包含惡意代碼。
不要在不了解更改的情況下更新庫
在升級之前查看您使用的任何庫的更改日誌。確保升級增加價值，並檢查維護者是否仍然是您信任的一方。
安裝看門狗庫作為開發或測試依賴項
使用諸如Snyk 之類的庫來掃描您的項目以查找不安全的依賴項。
設置功能監控；庫更新後檢查
如果您使用Cloud Functions 記錄器 SDK ，您可以監控異常行為並收到警報，包括由庫更新引起的行為。
雲功能安全
切勿將敏感信息放入 Cloud Functions 的環境變量中
通常在自託管 Node.js 應用程序中，您使用環境變量來包含敏感信息，如私鑰。不要在 Cloud Functions 中執行此操作。由於 Cloud Functions 在函數調用之間重用環境，因此不應將敏感信息存儲在環境中。
- 要存儲非 secret的 Firebase API 密鑰，只需將它們嵌入代碼中即可。
- 如果您在 Cloud Functions 中使用 Firebase Admin SDK，則無需明確提供服務帳戶憑據，因為 SDK 可以在初始化期間自動獲取它們。
- 如果您調用需要服務帳戶憑據的 Google 和 Google Cloud API，Node.js 的 Google Auth 庫可以從應用程序默認憑據中獲取這些憑據，這些憑據會自動填充到 Cloud Functions 中。
- 要使您的 Cloud Functions 可以使用非 Google 服務的私鑰和憑據，請使用Cloud Secret Manager 。
加密敏感信息
如果您無法避免將敏感信息傳遞給您的 Cloud Function，則必須提出自己的自定義解決方案來加密信息。
簡單的功能更安全；如果您需要復雜性，請考慮 Cloud Run
盡量讓您的 Cloud Functions 盡可能簡單易懂。功能的複雜性通常會導致難以發現的錯誤或意外行為。
如果您確實需要復雜的邏輯或環境配置，請考慮使用Cloud Run而不是 Cloud Functions。