הימנעות מכללים לא מאובטחים

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

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

גישה ל-Firebase Security Rules

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

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

כדי לגשת לכללים מה-CLI של Firebase, צריך לעבור אל מצוין קובץ הכללים בקובץ firebase.json.

הסבר על Firebase Security Rules

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

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

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

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

גישה פתוחה

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

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

Cloud Firestore

// Allow read/write access to all users under any conditions
// Warning: **NEVER** use this ruleset in production; it allows
// anyone to overwrite your entire database.

service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if true;
    }
  }
}

Realtime Database

{
  // Allow read/write access to all users under any conditions
  // Warning: **NEVER** use this ruleset in production; it allows
  // anyone to overwrite your entire database.

  "rules": {
    ".read": true,
    ".write": true
  }
}
    

Cloud Storage

// Anyone can read or write to the bucket, even non-users of your app.
// Because it is shared with App Engine, this will also make
// files uploaded via App Engine public.
// Warning: This rule makes every file in your Cloud Storage bucket accessible to any user.
// Apply caution before using it in production, since it means anyone
// can overwrite all your files.

service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read, write;
    }
  }
}
    
פתרון: כללים שמגבילים את הקריאה גישת כתיבה.

יוצרים כללים שתואמים להיררכיית הנתונים. אחד הפתרונות הנפוצים מבחינת רמת האבטחה הזו, היא מבוססת על אבטחה מבוססת-משתמש בעזרת Firebase Authentication. מידע נוסף אימות משתמשים באמצעות כללים

Cloud Firestore

Realtime Database

Cloud Storage

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

לפעמים, Rules בודק אם משתמש מחובר, אבל לא מגביל את הגישה על סמך האימות הזה. אם אחד מהכללים כולל auth != null, עליך לאשר שברצונך שכל משתמש מחובר יקבל גישה אל .

לא מומלץ: לכל משתמש שמחובר יש גישת קריאה וכתיבה לכל מסד הנתונים.

Cloud Firestore

service cloud.firestore {
  match /databases/{database}/documents {
    match /some_collection/{document} {
      allow read, write: if request.auth.uid != null;
    }
  }
}

Realtime Database

{
  "rules": {
    ".read": "auth.uid !== null",
    ".write": "auth.uid !== null"
  }
}

Cloud Storage

// Only authenticated users can read or write to the bucket
service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read, write: if request.auth != null;
    }
  }
}
הפתרון: צמצום הגישה באמצעות אבטחה את התנאים וההגבלות.

כשבודקים את האימות, כדאי להשתמש גם של מאפייני האימות כדי להגביל עוד יותר את הגישה למשתמשים ספציפיים לקבוצות נתונים ספציפיות. מידע נוסף על ההבדלים מאפייני אימות.

Cloud Firestore

Realtime Database

Cloud Storage

(Realtime Database) כללים שעברו בירושה באופן שגוי

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

לא מומלץ: צמצום כללים בנתיבים צאצאים
{
  "rules": {
     "foo": {
        // allows read to /foo/*
        ".read": "data.child('baz').val() === true",
        "bar": {
          /* ignored, since read was allowed already */
          ".read": false
        }
     }
  }
}
הפתרון: כתבו כללים בנתיבי הורה שהן רחבות, ומעניקות הרשאות ספציפיות יותר בנתיבי הצאצאים אם נדרשת גישה לנתונים ברמת פירוט גבוהה יותר, כדאי להגדיר כללים מפורטים. מידע נוסף על Realtime Database Security Rules מדורג מופיע בקטע תחביר הליבה של Realtime Database Security Rules.

גישה סגורה

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

Cloud Firestore

// Deny read/write access to all users under any conditions
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if false;
    }
  }
}

Realtime Database

{
  "rules": {
    ".read": false,
    ".write": false
  }
}
    

Cloud Storage

// Access to files through Cloud Storage is completely disallowed.
// Files may still be accessible through App Engine or Google Cloud Storage APIs.

service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read, write: if false;
    }
  }
}

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

מידע נוסף על Cloud Firestore Security Rules ועל אופן הפעולה שלהם ב- תחילת העבודה עם Cloud Firestore Security Rules.

בדיקה של Cloud Firestore Security Rules

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

כדי לאמת במהירות את Firebase Security Rules במסוף Firebase, משתמשים סימולטור הכללים של Firebase.