Firebase 安全檢查表

為了確保您的 Firebase 資源和使用者資料的安全,請遵循這些指南。並非每個專案都一定適用於您的要求,但在開發應用程式時請記住它們。

避免濫用流量

設定後端服務的監控和警報

若要偵測濫用流量,例如拒絕服務 (DOS) 攻擊,請為Cloud Firestore即時資料庫雲端儲存託管設定監控和警報

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

啟用應用程式檢查

為了幫助確保只有您的應用程式可以存取您的後端服務,請為支援它的每項服務啟用應用程式檢查

配置您的 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 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 控制台中的 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 logger 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 中)取得這些憑證。
  • 若要讓非 Google 服務的私鑰和憑證可供您的 Cloud Functions 使用,請使用Cloud Secret Manager

加密敏感訊息

如果您無法避免將敏感資訊傳遞到雲端功能,則必須提出自己的自訂解決方案來加密訊息。

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

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

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