Firebase: הפרדת זהות, הרשאות, אחסון והודעות

בקצרה

Firebase כולל שירותים עם SDK, בקרות ותנאי תמחור שונים. זיהוי משתמש אינו מתיר גישה לכל הנתונים. יש להעריך אבטחה ועלות לכל שירות.

חדר אימות זהות בדיוני וריק עם שני מפתחות אבטחה, כרטיס ריק ותיק בורדו
במאמר זה

Firebase כולל שירותים עם SDK, בקרות ותנאי תמחור שונים. זיהוי משתמש אינו מתיר גישה לכל הנתונים. יש להעריך אבטחה ועלות לכל שירות.

אימות והרשאה

Firebase Authentication מנהל כניסה; הרשאות דורשות הגדרה נפרדת. לקוחות אינטרנט ונייד של Cloud Firestore משתמשים ב־Security Rules. ספריות שרת עוקפות אותן ומשתמשות ב־IAM; בקרה אחת אינה מכסה את שני המסלולים. ה־MFA לאינטרנט המתועד מחייב Firebase Authentication with Identity Platform.

נתונים וקבצים

Cloud Firestore ו־Realtime Database הם שירותי מסדי נתונים נפרדים; Cloud Storage מאחסן אובייקטים כגון קבצים. אין כלל אבטחה יחיד המשותף להם. לפי ה־FAQ הנוכחי נדרש Blaze לשימוש ב־Cloud Storage for Firebase, גם בדליים קיימים; ייתכנו עדיין מכסות ללא תשלום. יש לבדוק מכסות וחיוב לפני הצגת מבנה כחינמי.

הודעות FCM

FCM HTTP v1 משתמש בהרשאות שרת, כולל אסימוני גישה קצרי חיים של OAuth 2.0. יש לשלוח מסביבה מהימנה בלי להטמיע פרטי ניהול בלקוח. אסימון רישום מכשיר מזהה יעד; הוא אינו ID token של משתמש או הרשאה עסקית.

הפעלות ותפעול

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

מקורות

בדיקה עריכתית: 1 בנובמבר 2026.

העברת החלטות זהות לרזולוטורים.

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

  • בדיקת אותו שדה תחת מספר תפקידים ובעלים.
  • מניעת גישה לאובייקט לפני חישוב שדות מקוננים.
  • הפעלה חוזרת לאחר שינויי תפקיד או ביטול הפעלה.

מקור ראשוני: OWASP — GraphQL Cheat Sheet. שיטה קשורה: קריאת המדריך המעשי.

דפדוף API וייצוא עקבי

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

  • תעדו מסננים, מיון ומפתח הכרעה לערכים שווים. בדקו אם ה־API מספק תמונת מצב או אוסף משתנה. בדקו יצירה ומחיקה בזמן קריאה; סמן אינו מבטיח שהנתונים קפואים.
  • ב־AIP-158 ערך next_page_token ריק מסיים קריאה, ולא עמוד תוצאות קצר או ריק. בעמודים בדיוניים [A,B] ו־[B,C] יש ארבע שורות אך שלושה מזהים ייחודיים. זהו גם סמן חוזר בלי התקדמות ופעלו לפי הסכם ה־API בפועל.
  • שמרו את האצווה באופן עמיד לפני אישור ההמשך. חזרו על אצווה שנקטעה עם מזהים יציבים ובדקו הרשאות בכל בקשה; סמן אינו אישור גישה. אם תמונת מצב פגה, התחילו מחדש או התאימו לפי מדיניות מפורשת; אל תאחדו מצבים שונים בשקט.

מקרה קבלה שניתן לשחזר

דוגמה בדיונית: הנתונים אינם מתארים לקוח או תוצאה שנצפתה.

הצגת נתוני המקרה
{
    "page_1_ids": [
        "A",
        "B"
    ],
    "page_2_ids": [
        "B",
        "C"
    ],
    "next_cursor": "c2",
    "empty_page_has_next_cursor": true
}

החלטה צפויה

B חוזר. בדקו מזהים והמשיכו עם הסמן הבא גם אחרי עמוד ריק.

נוהל בדיקה

  1. הגדירו מסננים, סדר יציב וזהות עצמים.
  2. בדקו כפילות ועמוד ריק עם סמן.
  3. שמרו מזהים ותנאי סיום אמיתי. השוו בין עצמים שהתקבלו למזהים ייחודיים; סמנו סמן חוזר ואל תחשיבו עמוד ריק שיש לו המשך כסיום האיסוף.

Google AIP-158 — Pagination

האם מספר השורות הצפוי מוכיח שהייצוא שלם?

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

מקור ראשוני: Google AIP-158 — Pagination. שיטה קשורה: קריאת המדריך המעשי.

Passkeys: הכנה לשינוי דומיין ו־RP ID

להפריד בין חשבון, מקור אינטרנט ו־RP ID כדי למנוע קישור מחדש שקט של פרטי הזדהות.

  • תעדו מקורות ישנים וחדשים, RP ID וחשבונות קשורים. שם חשבון זהה אינו הופך passkey לתקף עבור RP ID אחר. בדקו צירופים מותרים ב־WebAuthn ונתיבי גישה זמינים בזמן המעבר.
  • בסביבת בדיקה מורשית בדקו challenge, מקור, RP ID ושיוך חשבון בספרייה מתאימה. נסו מקור לא צפוי ואתגר חוזר. שינוי RP ID דורש רישום חדש לאחר אימות; העתקת שורה אינה מעבירה מפתח.
  • בדקו משתמש עם פרטי הזדהות ישנים בלבד, שחזור וסשנים פתוחים. קבעו פתיחת נתיבים וסגירתם עם חזרה שנבדקה. רישום בדומיין חדש אינו מוכיח ביטול כל הסשנים הישנים.

מקרה קבלה שניתן לשחזר

דוגמה בדיונית: הנתונים אינם מתארים לקוח או תוצאה שנצפתה.

הצגת נתוני המקרה
{
    "old_origin": "https://login.old.example",
    "old_rp_id": "old.example",
    "new_origin": "https://login.new.example",
    "new_rp_id": "new.example",
    "same_service_account": true,
    "expected": "authenticated_new_registration"
}

החלטה צפויה

דוגמה בדיונית: החשבון זהה, אך old.example נעשה new.example עם RP ID אחר. אין לקשר מחדש בשקט את פרטי ההזדהות הישנים; הרישום החדש עובר בנתיב האימות המתוכנן.

W3C — Web Authentication Level 2

מקור ראשוני: W3C — Web Authentication Level 2. שיטה קשורה: קריאת המדריך המעשי.

זהות: גורמים, הפעלות ושחזור

Firebase: אסימון קצר אינו מסיים את ההפעלה כולה

לפי התיעוד ID token תקף לשעה, ואסימון רענון מאפשר לקבל חדשים. ביטול אסימוני רענון וזיהוי ביטול ID token הם בקרות שונות.

  • לקשר את הביטול לחשבון הרלוונטי.
  • להשתמש בבדיקת הביטול המתועדת ב־SDK, למשל checkRevoked.
  • לבדוק אסימון ישן בכל שרת מוגן וגם את ההרשאות.

להעמיק בבקרות זהות →

המקורות נבדקו בתאריך · NIST · Authenticator Event Management NIST · Session Management Firebase · Manage User Sessions