請參閱本指南,瞭解設定中常見的安全漏洞、檢查並加強保護自己的規則,以及在部署變更前進行測試。Cloud Firestore Security Rules
如果收到 Cloud Firestore 資料庫未妥善保護的快訊,可以修改及測試 Cloud Firestore Security Rules,解決安全漏洞。
如要查看現有的安全性規則,請前往 Firebase 控制台的「規則」分頁。
瞭解 Cloud Firestore Security Rules
Cloud Firestore Security Rules保護資料,避免遭到惡意使用者侵擾。在 Firebase 控制台中建立的任何 Cloud Firestore 執行個體,預設規則都會拒絕所有使用者存取。如要開發應用程式及存取資料庫,您需要修改這些規則,並考慮在開發環境中授予所有使用者全面存取權。不過,在將應用程式部署至正式環境之前,請花時間正確設定規則並保護資料。
開發應用程式並測試規則的不同設定時,請使用 Cloud Firestore 模擬器在本機開發環境中執行應用程式。
安全性偏低的規則常見情境
您可能已預設或在最初使用 Cloud Firestore 開發應用程式時設定 Cloud Firestore Security Rules,但請務必在部署應用程式前檢查並更新。請避免下列常見錯誤,確保使用者資料安全無虞。
公開存取
設定 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 Authentication。進一步瞭解如何使用規則驗證使用者。 |
僅限內容擁有者
service cloud.firestore { match /databases/{database}/documents { // Allow only authenticated content owners access match /some_collection/{document} { // Allow reads and deletion if the current user owns the existing document allow read, delete: if request.auth.uid == resource.data.author_uid; // Allow creation if the current user owns the new document allow create: if request.auth.uid == request.resource.data.author_uid; // Allow updates by the owner, and prevent change of ownership allow update: if request.auth.uid == request.resource.data.author_uid && request.auth.uid == 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 public reads allow read: if true // Allow creation if the current user owns the new document allow create: if request.auth.uid == request.resource.data.author_uid; // Allow updates by the owner, and prevent change of ownership allow update: if request.auth.uid == request.resource.data.author_uid && request.auth.uid == resource.data.author_uid; // Allow deletion if the current user owns the existing document allow delete: if request.auth.uid == resource.data.author_uid; } } }
任何已驗證的使用者都能存取
有時,Cloud Firestore Security Rules 會檢查使用者是否已登入,但不會根據該驗證進一步限制存取權。如果其中一項規則包含 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 } } }
未經驗證電子郵件地址的存取權
有時,Cloud Firestore Security Rules請檢查使用者的電子郵件是否屬於特定網域。雖然這通常是不錯的做法,但使用者收到驗證電子郵件後,必須執行額外步驟,系統才會在登入期間驗證電子郵件。請務必驗證電子郵件地址確實屬於使用者。
不建議:任何使用者都能以任意電子郵件地址登入。 |
service cloud.firestore { match /databases/{database}/documents { // Allow access based on email domain match /some_collection/{document} { allow read: if request.auth != null && request.auth.email.endsWith('@example.com') } } }
解決方案:將存取權限縮至僅限已驗證的電子郵件地址。 |
驗證電子郵件
service cloud.firestore { match /databases/{database}/documents { // Allow access based on email domain match /some_collection/{document} { allow read: if request.auth != null && request.auth.email_verified && request.auth.email.endsWith('@example.com') } } }
封閉測試
開發應用程式時,另一種常見做法是將資料鎖定。通常這表示您已對所有使用者關閉讀取和寫入存取權,如下所示:
// 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 仍可存取資料庫。如果您打算搭配 Firebase Admin SDK,將 Cloud Firestore 做為僅限伺服器的後端,請使用這些規則。雖然安全無虞,但您應測試應用程式的用戶端是否能正確擷取資料。
如要進一步瞭解 Cloud Firestore Security Rules 和運作方式,請參閱「開始使用 Cloud Firestore Security Rules」。
請查看「Cloud Firestore Security Rules」
如要檢查應用程式的行為並驗證 Cloud Firestore Security Rules 設定,請使用 Cloud Firestore 模擬器。在部署任何變更之前,請先使用 Cloud Firestore 模擬器在本機環境中執行及自動化單元測試。
如要在 Firebase 控制台中快速測試更新後的 Cloud Firestore Security Rules,請使用規則遊樂場工具。
- 如要開啟規則遊樂場,請按一下「規則」分頁中的「規則遊樂場」。
- 在「規則遊樂場」設定中,選取測試選項,包括:
- 測試讀取或寫入作業
- 資料庫中的特定「位置」,以路徑形式表示
- 驗證類型:未通過驗證、已通過驗證的匿名使用者,或特定使用者 ID
- 規則明確參照的文件專屬資料 (例如,規則要求必須有特定欄位,才能允許寫入)
- 按一下「執行」,然後在規則視窗上方的橫幅中查看結果。