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

המדריך הזה יעזור לכם להבין נקודות חולשה נפוצות בהגדרות של 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;
    }
  }
}

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

במדריך לתחילת העבודה עם Cloud Firestore Security Rules מוסבר מה זה Cloud Firestore Security Rules ואיך משתמשים בו.

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

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

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

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