תיקון כללים לא מאובטחים

במדריך הזה מוסבר איך לזהות נקודות חולשה נפוצות בהגדרות של Cloud Firestore Security Rules, איך לבדוק את הכללים שלכם ולשפר את האבטחה שלהם, ואיך לבדוק את השינויים לפני הפריסה שלהם.

אם תקבלו התראה על כך שמסד הנתונים Cloud Firestore לא מאובטח כראוי, תוכלו לפתור את נקודות החולשה על ידי שינוי ה-Cloud Firestore Security Rules ובדיקה שלו.

כדי להציג את כללי האבטחה הקיימים, עוברים אל הכרטיסייה Rules במסוף Firebase.

הסבר על Cloud Firestore Security Rules

Cloud Firestore Security Rules להגן על הנתונים מפני משתמשים זדוניים. כללי ברירת המחדל לכל מכונה של Cloud Firestore שנוצרת במסוף Firebase מונעים גישה לכל המשתמשים. כדי לפתח את האפליקציה ולגשת למסד הנתונים, תצטרכו לשנות את הכללים האלה. מומלץ להעניק גישה גורפת לכל המשתמשים בסביבת הפיתוח. עם זאת, לפני שפורסים את האפליקציה בסביבת הייצור, כדאי להקדיש זמן להגדרה נכונה של הכללים ולהגנה על הנתונים.

במהלך הפיתוח של האפליקציה ובדיקת ההגדרות השונות של הכללים, תוכלו להשתמש במעבד Cloud Firestore כדי להריץ את האפליקציה בסביבת פיתוח מקומית.

תרחישים נפוצים עם כללים לא מאובטחים

לפני פריסת האפליקציה, צריך לבדוק ולעדכן את Cloud Firestore Security Rules שהגדרתם כברירת מחדל או במהלך הפיתוח הראשוני של האפליקציה באמצעות Cloud Firestore. כדי לוודא שאתם מאבטחים כראוי את נתוני המשתמשים, כדאי להימנע מהמלכודות הנפוצות הבאות.

גישה פתוחה

כשמגדירים את Cloud Firestore, יכול להיות שהגדרתם את הכללים כך שיאפשרו גישה פתוחה במהלך הפיתוח. יכול להיות שאתם חושבים שאתם היחידים שמשתמשים באפליקציה שלכם, אבל אם פרסתם אותה, היא זמינה באינטרנט. אם לא מבצעים אימות משתמשים והגדרת כללי אבטחה, כל מי שיחליט לנחש את מזהה הפרויקט יוכל לגנוב, לשנות או למחוק את הנתונים.

לא מומלץ: הרשאת קריאה וכתיבה לכל המשתמשים.

// 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
    }
  }
}

גישה סגורה

בזמן הפיתוח של האפליקציה, גישה נפוצה נוספת היא לא לאפשר גישה לנתונים. בדרך כלל, המשמעות היא שחסמתם את הגישה לקריאה ולכתיבה לכל המשתמשים, באופן הבא:

// 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 Security Rules ועל אופן הפעולה שלו זמין במאמר תחילת העבודה עם Cloud Firestore Security Rules.

צריך לבדוק ב-Cloud Firestore Security Rules

כדי לבדוק את התנהגות האפליקציה ולאמת את ההגדרות של Cloud Firestore Security Rules, תוכלו להשתמש במכשיר האימולציה של Cloud Firestore. אפשר להשתמש במהדמטור Cloud Firestore כדי להריץ בדיקות יחידה בסביבה מקומית ולהפוך אותן לאוטומטיות לפני פריסת השינויים.

כדי לבדוק במהירות את Cloud Firestore Security Rules המעודכן במסוף Firebase, תוכלו להשתמש בכלי Rules Playground.

כדי לפתוח את Rules Playground, לוחצים על Rules playground בכרטיסייה Rules.
בהגדרות של Rules playground, בוחרים אפשרויות לבדיקה, כולל:
- בדיקת פעולות קריאה או כתיבת
- מיקום ספציפי במסד הנתונים, כנתיב
- סוג האימות – משתמש לא מאומת, משתמש אנונימי מאומת או מזהה משתמש ספציפי
- נתונים ספציפיים למסמך שהכללים מפנים אליהם באופן ספציפי (לדוגמה, אם הכללים דורשים נוכחות של שדה ספציפי לפני שמאפשרים כתיבת נתונים)
לוחצים על הפעלה ומחפשים את התוצאות בבאנר שמעל חלון הכללים.