Firebase allow read, write: if true מוסבר: מה הוא עושה ואיך לתקן אותו

התחביר, שורה אחר שורה

מסמך חוקי מצב-בדיקה מלא של Firestore הוא שש שורות:

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

מפוענח:

• rules_version = '2'; בוחר את מנוע החוקים v2 (הנוכחי). חוקי v1 ישנים יותר הוצאו משימוש.
• service cloud.firestore מצמצם את הבלוק ל-Firestore. Realtime Database משתמש בתחביר אחר מבוסס-JSON; Cloud Storage משתמש ב-service firebase.storage.
• match /databases/{database}/documents קושר את מסד הנתונים המיוחד (default) (לרוב הפרויקטים יש רק אחד).
• match /{document=**} הוא wildcard רקורסיבי. ה-** תואם לכל נתיב בכל עומק. בשילוב עם {document}, זה תופס כל מסמך בכל אוסף — תניית התאמה אחת ששולטת בכל מסד הנתונים.
• allow read, write: if true; הוא גוף החוק. גם read וגם write מותרים; התנאי if true הוא, ובכן, תמיד נכון. read מכסה פעולות get ו-list; write מכסה create, update, ו-delete.

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

מדוע Firebase שולח את זה כברירת מחדל

Firebase רוצה שתהיה בקידוד בתוך 30 השניות הראשונות אחרי יצירת פרויקט. החלופה — לאלץ אותך לכתוב חוק נכון לפני שקריאה או כתיבה כלשהי עובדות — תחסום onboarding. אז הקונסולה מציעה שתי אפשרויות כשאתה יוצר מסד נתונים: Production mode (לשלול הכל, אתה כותב את החוקים) או Test mode (להתיר הכל ל-30 ימים). רוב המפתחים לוחצים מצב-בדיקה, ואז שוכחים לחזור. פרויקטים ישנים יותר היו עם הטיימר של 30 הימים; פרויקטים נוכחיים יש להם חוק if true בלתי-מוגבל ללא תפוגה אוטומטית.

הבעיה המבנית: כלי קוד מבוססי-AI אומנו על תיעוד, מדריכים, ותשובות Stack Overflow שמראים חוקי מצב-בדיקה. כשאתה שואל את Cursor או Claude Code "איך אני מגדיר Firebase", התשובה לעיתים תכופות כוללת את בלוק allow read, write: if true המדויק כאילו היה חוק הייצור. ה-AI לא יודע — ולא מתבקש לדעת — שהחוק הזה לא בטוח לייצור.

מה תוקף רואה

באופן ממשי, תוקף שיודע את מזהה פרויקט ה-Firebase שלך (ניתן לחילוץ מחבילה של כל אפליקציה מותקנת תוך 30 שניות) ומריץ את הבא יכול לרשום כל מסמך בכל אוסף:

בקשת curl לא-מאומתת אחת מספיקה כדי למנות כל אוסף. ראה את הבלוק המודגש מטה.

curl 'https://firestore.googleapis.com/v1/projects/[project-id]/databases/(default)/documents:listCollectionIds' \
  -X POST \
  -H 'Content-Type: application/json' \
  -d '{}'

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

בנתיב הכתיבה: POST בודד עם {fields} יוצר מסמך חדש. תוקפים יכולים לזהם את האוספים שלך עם זבל, להשחית דפים מול-משתמש שקוראים מ-Firestore, או להשתמש במסד הנתונים שלך כברוקר הודעות חינמי — חשבון השימוש שלך מזנק, אתה חוקר, החשבון מסביר את הבעיה.

ארבעה תחליפים בטוחים לייצור

בחר את התחליף שמתאים למודל הנתונים של האפליקציה שלך. כל הארבעה מניחים שיש לך אימות משתמשים (Firebase Auth או כל ספק שמנפיק טוקן ID של Firebase):

אפשרות 1: מסמכים בבעלות המשתמש

דפוס SaaS הנפוץ ביותר. מסמכים חיים תחת /users/{userId}/... ורק הבעלים יכול לגעת בהם. match /users/{userId}/{document=**} { allow read, write: if request.auth != null && request.auth.uid == userId; }

match /users/{userId}/{document=**} {
  allow read, write: if request.auth != null
                     && request.auth.uid == userId;
}

אפשרות 2: שדה בעלים על כל מסמך

כשמסמכים חיים באוספים שטוחים (לא מקוננים תחת מזהה משתמש), אחסן שדה owner_uid ובדוק אותו. match /posts/{postId} { allow read: if resource.data.public == true || resource.data.owner_uid == request.auth.uid; allow write: if request.auth.uid == resource.data.owner_uid; }

match /posts/{postId} {
  allow read:  if resource.data.public == true
              || resource.data.owner_uid == request.auth.uid;
  allow write: if request.auth.uid == resource.data.owner_uid;
}

אפשרות 3: בידוד ארגון רב-דייר

עבור B2B SaaS עם נתונים מצומצמי-ארגון. אחסן שדה org_id על כל מסמך ובדוק אותו מול ה-custom claim של המשתמש. allow read, write: if request.auth.token.org_id == resource.data.org_id;. דורש הגדרת ה-custom claim במהלך הרשמה דרך Firebase Admin SDK.

allow read, write: if request.auth.token.org_id == resource.data.org_id;

אפשרות 4: תוכן ציבורי לקריאה בלבד

עבור תוכן שיווקי, פרופילים ציבוריים, קטלוגי מוצרים — כל דבר שהוא באמת קריאה-ציבורית אך כתיבה-לאדמין-בלבד. match /products/{productId} { allow read: if true; allow write: if request.auth.token.admin == true; }. ה-custom claim admin מוגדר רק על חשבונות admin.

match /products/{productId} {
  allow read:  if true;
  allow write: if request.auth.token.admin == true;
}

שאילתת audit מהירה

לפני תיקון, בדוק אם if true בעצם פעיל. פתח Firebase Console → Firestore → Rules וחפש if true. אם אתה מוצא אותו בכל מקום מחוץ להערה, יש לך ממצא של חוק פתוח. סימולטור החוקים באותו UI מאפשר לך לשחזר את בקשת התוקף מקומית — הדבק GET /users/somebody אנונימי ואשר שהסימולטור מחזיר Allowed.

אישור חיצוני: הרץ סריקת FixVibe מול URL הייצור שלך. בדיקת baas.firebase-rules בוחנת את חוקי ה-Firestore, Realtime Database, וה-Storage שלך ומדווחת על אותו ממצא שתוקף היה מגלה — בלתי-תלוי במה שקונסולת Firebase מראה.

שאלות נפוצות

צעדים הבאים

הרץ סריקת FixVibe מול URL הייצור שלך — בדיקת baas.firebase-rules מאשרת אם if true ניתן לניצול כרגע מהאינטרנט הציבורי. למכניקות הסורק והזיהויים המקבילים עבור Realtime Database ו-Storage, ראה סורק חוקי Firebase. למחלקת התצורה השגויה המקבילה ב-Supabase, קרא סורק Supabase RLS.