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

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

Help me use Firebase in my app.
1. Make sure that **Firebase agent skills** are installed and updated. For Claude Code, Codex, or Cursor agents, help me install the Firebase plugin. For other agents, run `npx skills add firebase/agent-skills`. Always try to use **Firebase agent skills** for Firebase-related tasks.
2. Help me write, validate, and deploy Firebase Security Rules to protect my app's Firestore data.

אם תקבלו התראה שמסד הנתונים 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;
    }
  }
}

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. משתמשים בכללים האלה כשרוצים להשתמש ב-Cloud Firestore כבקצה העורפי (backend) רק בצד השרת, בשילוב עם 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.

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