Join us in person and online for Firebase Summit on October 18, 2022. Learn how Firebase can help you accelerate app development, release your app with confidence, and scale with ease. Register now

Firebase 安全清單

透過集合功能整理內容 你可以依據偏好儲存及分類內容。

為確保您的 Firebase 資源和用戶數據的安全,請遵循這些準則。並非每個項目都一定適用於您的要求,但在開發應用程序時請牢記它們。

避免濫用流量

為後端服務設置監控和警報

要檢測濫用流量,例如拒絕服務 (DOS) 攻擊,請為Cloud FirestoreRealtime DatabaseCloud StorageHosting設置監控和警報

如果您懷疑您的應用程序受到攻擊,請盡快聯繫支持人員,讓他們知道發生了什麼。

啟用應用檢查

為了幫助確保只有您的應用程序可以訪問您的後端服務,請為支持它的每個服務啟用應用程序檢查

配置您的 Cloud Functions 以針對正常流量進行擴展

Cloud Functions 會自動擴展以滿足您的應用程序的需求,但如果發生攻擊,這可能意味著巨額費用。為防止這種情況,您可以根據應用的正常流量限制函數的並發實例數

設置警報以在接近達到限制時收到通知

如果您的服務有請求高峰,通常會啟動配額,並自動限制您的應用程序的流量。確保監控您的使用和計費儀表板,但您也可以在項目上設置預算警報,以便在資源使用超出預期時收到通知。

防止自我DOS:使用模擬器在本地測試功能

在開發 Cloud Functions 時,很容易意外地執行 DOS:例如,通過創建無限的觸發-寫入循環。您可以通過使用Firebase 模擬器套件進行開發來防止這些錯誤影響實時服務。

(如果您自己不小心執行了 DOS,請通過從index.js中刪除它然後運行firebase deploy --only functions來取消部署您的函數。)

在實時響應不那麼重要的地方,結構具有防禦性功能

如果您不需要實時呈現函數的結果,您可以通過批量處理結果來緩解濫用流量:將結果發佈到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、實時數據庫和 Cloud Storage 時,初始化您的安全規則以默認拒絕所有訪問,並在您開發應用程序時添加規則以授予對特定資源的訪問權限。

這是 Cloud Firestore(生產模式)和實時數據庫(鎖定模式)新實例的默認設置之一。設置新數據庫實例時選擇此選項。

對於 Cloud Storage,請從如下所示的安全規則配置開始:

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

安全規則是一種模式;添加文檔時添加規則

不要在編寫應用程序後編寫安全規則,作為一種啟動前任務。相反,在編寫應用程序時編寫安全規則,將它們視為數據庫模式:每當您需要使用新的文檔類型或路徑結構時,首先編寫其安全規則。

使用模擬器套件對安全規則進行單元測試;將其添加到 CI

為確保您的安全規則跟上應用程序的開發,請使用Firebase 模擬器套件對您的規則進行單元測試,並將這些測試添加到您的 CI 管道中。請參閱Cloud Firestore實時數據庫的這些指南。

驗證

自定義身份驗證:來自受信任(服務器端)環境的薄荷 JWT

如果您已經擁有一個安全的登錄系統,無論是自定義系統還是第三方服務,您都可以使用現有系統來通過 Firebase 服務進行身份驗證。從受信任的環境中創建自定義 JWT ,然後將令牌傳遞給您的客戶端,該客戶端使用令牌進行身份驗證( iOS+AndroidWebUnityC++ )。

有關使用第三方提供商的自定義身份驗證的示例,請參閱博客文章使用 Okta 使用 Firebase 進行身份驗證

託管身份驗證:OAuth 2.0 提供者是最安全的

如果您使用 Firebase 的託管身份驗證功能,OAuth 2.0 / OpenID Connect 提供程序選項(Google、Facebook 等)是最安全的。如果可以(取決於您的用戶群),您應該支持這些提供商中的一個或多個。

電子郵件密碼身份驗證:為登錄端點設置嚴格的配額以防止暴力攻擊

如果您使用 Firebase 的託管電子郵件密碼身份驗證服務,請收緊identitytoolkit.googleapis.com端點的默認配額以防止暴力攻擊。您可以從Google Cloud Console 中的 API 頁面執行此操作

升級到 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 Function 的環境變量中

通常在自託管 Node.js 應用程序中,您使用環境變量來包含敏感信息,例如私鑰。不要在 Cloud Functions 中執行此操作。由於 Cloud Functions 在函數調用之間重用環境,因此不應將敏感信息存儲在環境中。

  • 要存儲非機密的 Firebase API 密鑰,只需將它們嵌入代碼中即可。
  • 如果您在 Cloud Function 中使用 Firebase Admin SDK,則無需顯式提供服務帳號憑據,因為 SDK 可以在初始化期間自動獲取它們。
  • 如果您調用需要服務帳戶憑據的 Google 和 Google Cloud API,Node.js 的 Google Auth 庫可以從應用程序默認憑據中獲取這些憑據,這些憑據會自動填充到 Cloud Functions 中。
  • 要為您的 Cloud Functions 提供非 Google 服務的私鑰和憑據,請使用Cloud Secret Manager

加密敏感信息

如果您無法避免將敏感信息傳遞給您的雲函數,則必須提出自己的自定義解決方案來加密信息。

簡單的功能更安全;如果您需要復雜性,請考慮 Cloud Run

盡量使您的雲功能盡可能簡單易懂。函數的複雜性通常會導致難以發現的錯誤或意外行為。

如果您確實需要復雜的邏輯或環境配置,請考慮使用Cloud Run而不是 Cloud Functions。