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

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

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

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

הסבר על כללי האבטחה של Firestore

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

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

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

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

גישה פתוחה

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

לא מומלץ: הרשאת קריאה וכתיבה לכל המשתמשים. 
// 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 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;
    }
  }
}

גישה לכל משתמש מאומת

לפעמים, כללי האבטחה של 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
    }
  }
}

גישה לכתובות אימייל לא מאומתות

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

לא מומלץ: כל משתמש יכול להיכנס באמצעות כתובת אימייל שרירותית. 
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 עדיין יכולות לגשת למסד הנתונים. כדאי להשתמש בכללים האלה אם אתם מתכוונים להשתמש ב-Firestore במצב Native כבקצה העורפי רק בשרת בשילוב עם Firebase Admin SDK. למרות שזה מאובטח, כדאי לבדוק שלקוחות האפליקציה יכולים לאחזר נתונים בצורה תקינה.

מידע נוסף על כללי אבטחה ב-Firestore ועל אופן הפעולה שלהם זמין במאמר תחילת העבודה עם כללי אבטחה ב-Firestore.

בדיקת כללי האבטחה של Firestore

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

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

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