使用本指南可了解 Cloud Firestore 安全規則配置中的常見漏洞,查看並更好地保護您自己的規則,並在部署變更之前測試您的變更。
如果您收到有關 Cloud Firestore 資料庫未適當保護的警報,您可以透過修改和測試 Cloud Firestore 安全規則來解決漏洞。
若要查看現有的安全性規則,請前往 Firebase 控制台中的「規則」標籤。
了解您的 Cloud Firestore 安全性法則
Cloud Firestore 安全性規則可保護您的資料免受惡意使用者的侵害。在 Firebase 控制台中建立的任何 Cloud Firestore 執行個體的預設規則都會拒絕所有使用者的存取。要開發應用程式並存取資料庫,您需要修改這些規則,並可能考慮向開發環境中的所有使用者授予全面存取權限。但是,在將應用程式部署到生產環境之前,請花一些時間正確配置規則並保護資料。
當您開發應用程式並測試規則的不同配置時,請使用Cloud Firestore 模擬器在本機開發環境中執行您的應用程式。
規則不安全的常見場景
在部署應用程式之前,應檢查並更新您預設設定的或最初使用 Cloud Firestore 開發應用程式時設定的 Cloud Firestore 安全性規則。透過避免以下常見陷阱,確保正確保護用戶資料。
開放獲取
在設定 Cloud Firestore 時,您可能已設定規則以允許在開發期間進行開放存取。您可能認為您是唯一使用您的應用程式的人,但如果您部署了它,它就可以在互聯網上使用。如果您沒有對使用者進行身份驗證並配置安全性規則,那麼任何猜測您的專案 ID 的人都可以竊取、修改或刪除資料。
不推薦:所有使用者都具有讀寫權限。 |
// Allow read/write access to all users under any conditions // Warning: **NEVER** use this rule set in production; it allows // anyone to overwrite your entire database. service cloud.firestore { match /databases/{database}/documents { match /{document=**} { allow read, write: if true; } } }
解決方案:限制讀寫存取的規則。 建立對您的資料層次結構有意義的規則。解決這種不安全問題的常見解決方案之一是使用 Firebase 驗證來實現基於使用者的安全性。了解有關使用規則驗證使用者身分的更多資訊。 |
限內容所有者
service cloud.firestore { match /databases/{database}/documents { // Allow only authenticated content owners access match /some_collection/{document} { allow read, write: if request.auth != null && request.auth.uid == request.resource.data.author_uid } } }
公共和私人混合訪問
service cloud.firestore { match /databases/{database}/documents { // Allow public read access, but only content owners can write match /some_collection/{document} { allow read: if true allow write: if request.auth != null && request.auth.uid == request.resource.data.author_uid } } }
任何經過身份驗證的用戶都可以訪問
有時,Cloud Firestore 安全性規則會檢查使用者是否已登錄,但不會根據該驗證進一步限制存取。如果您的規則之一包含auth != null
,請確認您希望任何登入使用者都有權存取資料。
不建議:任何登入使用者都具有對整個資料庫的讀寫存取權限。 |
service cloud.firestore { match /databases/{database}/documents { match /some_collection/{document} { allow read, write: if request.auth != null; } } }
解決方案:利用安全條件縮小存取範圍。 當您檢查身份驗證時,您可能還想使用身份驗證屬性之一來進一步限制特定使用者對特定資料集的存取。了解有關新增安全條件和基於角色的存取的更多資訊。 |
基於角色的訪問
service cloud.firestore { match /databases/{database}/documents { // Assign roles to all users and refine access based on user roles match /some_collection/{document} { allow read: if request.auth != null && get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "Reader" allow write: if request.auth != null && get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "Writer" // Note: Checking for roles in your database using `get` (as in the code // above) or `exists` carry standard charges for read operations. } } }
基於屬性的訪問
// Give each user in your database a particular attribute // and set it to true/false // Then, use that attribute to grant access to subsets of data // For example, an "admin" attribute set // to "true" grants write access to data service cloud.firestore { match /databases/{database}/documents { match /collection/{document} { allow write: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.admin == true; allow read: true; } } }
公共和私人混合訪問
service cloud.firestore { match /databases/{database}/documents { // Allow public read access, but only content owners can write match /some_collection/{document} { allow read: if true allow write: if request.auth.uid == request.resource.data.author_uid } } }
封閉訪問
在開發應用程式時,另一種常見方法是鎖定資料。通常,這表示您已關閉所有使用者的讀寫存取權限,如下所示:
// Deny read/write access to all users under any conditions
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read, write: if false;
}
}
}
Firebase Admin SDK 和 Cloud Functions 仍然可以存取您的資料庫。當您打算將 Cloud Firestore 與 Firebase Admin SDK 結合作為僅伺服器後端時,請使用這些規則。雖然它是安全的,但您應該測試應用程式的客戶端是否可以正確檢索資料。
若要詳細了解 Cloud Firestore 安全性規則及其運作原理,請參閱 Cloud Firestore 安全性規則入門。
檢查您的 Cloud Firestore 安全性規則
若要檢查應用程式的行為並驗證 Cloud Firestore 安全性規則配置,請使用Cloud Firestore 模擬器。在部署任何變更之前,使用 Cloud Firestore 模擬器在本機環境中執行和自動化單元測試。
若要在 Firebase 控制台中快速測試更新後的 Cloud Firestore 安全性規則,請使用 Rules Playground 工具。
- 若要開啟“規則遊樂場”,請按一下“規則”標籤中的“規則遊樂場” 。
- 在規則遊樂場設定中,選擇測試選項,包括:
- 測試讀取或寫入
- 資料庫中的特定位置,作為路徑
- 驗證類型 — 未經身份驗證、經過驗證的匿名使用者或特定使用者 ID
- 您的規則特別引用的文件特定資料(例如,如果您的規則要求在允許寫入之前存在特定欄位)
- 點擊“運行”並在規則視窗上方的橫幅中尋找結果。