אבטחה באפליקציות וייב קודינג (Vibe Coding): מה פיירבייס (Firebase) לא עושה בשבילכם

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

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

בקצרה

למה התחברות דרך גוגל לא מגינה על הנתונים

יש שתי שאלות נפרדות בכל מערכת: מי אתה, ומה מותר לך. הראשונה נקראת אימות (Authentication), והשנייה הרשאה (Authorization). כשמשתמשת מתחברת עם גוגל, פיירבייס יודעת בוודאות שזו היא. זה הכול.

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

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

גם בקהילה המקצועית זה ידוע. ברשימת OWASP Top 10, הרשימה המוכרת ביותר של סיכוני אבטחה באפליקציות רשת, הקטגוריה שמדורגת במקום הראשון בגרסת 2025 היא Broken Access Control, כלומר כשל בבקרת גישה (OWASP Top 10:2025, נבדק ב-2026-10-19). זו בדיוק הבעיה שהתחברות לבדה לא פותרת.

מה זה כללי אבטחה (Security Rules) בפיירבייס

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

כשיוצרים מסד נתונים חדש ב-Firestore, מוצעים שני מצבים. לפי מדריך ההתחלה הרשמי, מצב בדיקה (Test mode) "מאפשר לכל אחד לקרוא ולדרוס את הנתונים שלכם", ומצב ייצור (Production mode) חוסם את כל הקריאות והכתיבות מאפליקציות ומדפדפנים. מצב בדיקה נוח מאוד לפיתוח, ולכן כלי AI ומדריכים מהירים בוחרים בו לא פעם. הבעיה מתחילה כשהוא נשאר כך גם אחרי ההשקה.

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

1. גישה פתוחה לגמרי. כלל כמו allow read, write: if true;. לפי פיירבייס, כל מי שמנחש את מזהה הפרויקט יכול לגנוב, לשנות או למחוק את הנתונים.
2. גישה לכל משתמש מחובר. כלל כמו allow read, write: if request.auth.uid != null;. הוא נראה מאובטח, כי הוא דורש התחברות, אבל הוא מתיר לכל משתמש מחובר לקרוא ולשנות את כל המסמכים באוסף, כולל של אחרים. פיירבייס ממליצה לוודא שזה באמת מה שהתכוונתם.
3. ירושה שגויה ב-Realtime Database. שם הכללים עוברים מהנתיב העליון לנתיבים שמתחתיו, ולפי התיעוד אי אפשר לבטל בנתיב עמוק גישה שכבר ניתנה בנתיב שמעליו.

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

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

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

מפתחות חשופים: איזה מפתח מותר לראות ואיזה לא

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

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

מה שכן צריך להדאיג:

• מפתח של Gemini API. לפי אותו עמוד, הוא לעולם לא צריך להופיע בקוד או בקבצי הגדרות. זה רלוונטי במיוחד לאפליקציות שמוסיפות "צ'אט AI": מפתח כזה בדפדפן מאפשר לכל אחד להשתמש בו על חשבונכם.
• מפתחות פרטיים של חשבון שירות (service account). לפי רשימת הבדיקה של פיירבייס, הם רגישים וחייבים להישאר סודיים, כי הם נותנים גישה מלאה מצד השרת.
• מפתחות שרת של FCM, שירות ההתראות של פיירבייס. אותה רשימה קובעת שיש לשמור אותם בסוד.

ומי שבונה על סופהבייס (Supabase) במקום פיירבייס, ההיגיון זהה, רק עם שמות אחרים:

לפי התיעוד של סופהבייס (נבדק ב-2026-10-19), המפתח הציבורי מגיע רק למה ש-RLS מתיר, ולכן צריך להפעיל RLS על כל טבלה לפני הפריסה, ומפתח secret עוקף את RLS ולכן אסור שיגיע לדפדפן, לאפליקציה או למאגר הקוד. מי שבונה עם קלוד קוד על סופהבייס ימצא את זה בפירוט במדריך לקלוד קוד (Claude Code) עם סופהבייס.

בדיקות בצד השרת: למה אסור לסמוך על הדפדפן

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

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

1. מחיר שנשלח מהדפדפן. אם עגלת הקניות שולחת "סכום לתשלום", משתמש יכול לשנות אותו. המחיר צריך להיקבע בשרת, לפי מזהה המוצר.
2. שדה תפקיד שהמשתמש יכול לכתוב. אם במסמך המשתמש יש isAdmin או role, וכללי האבטחה מתירים למשתמש לעדכן את המסמך שלו, הוא יכול להפוך את עצמו למנהל.
3. מזהה משתמש שמגיע מהלקוח. אם השרת מקבל "אני משתמש 123" ומאמין, כל אחד יכול להתחזות. לפי התיעוד של פיירבייס, אחרי ההתחברות שולחים לשרת את אסימון הזיהוי (ID token) ב-HTTPS, והשרת מאמת אותו ושולף ממנו את ה-uid בעצמו.

ונקודה הפוכה שחשוב להכיר: לפי התיעוד, ספריות השרת של Firestore עוקפות את כל כללי האבטחה. זה מכוון, כי השרת שלכם אמור להיות מהימן. אבל זה אומר שקוד בשרת (למשל Cloud Functions) חייב לבדוק הרשאות בעצמו, כי שם הכללים כבר לא עובדים בשבילכם.

למה "הקוד שה-AI כתב" לא מספיק

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

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

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

רשימת בדיקה לפני שיש משתמשים אמיתיים

את הרשימה הזו כדאי לעבור לפני שהמשתמש הראשון שאינו אתם נרשם. רוב הסעיפים מבוססים על רשימת הבדיקה הרשמית של פיירבייס (נבדק ב-2026-10-19):

1. בדקו באיזה מצב מסד הנתונים. פתחו את לשונית Rules בקונסולה. אם יש if true או כלל מבוסס תאריך ממצב בדיקה, הוא חייב להשתנות.
2. התחילו מחסימה מלאה. פיירבייס ממליצה על ברירת מחדל של סירוב, ופתיחת גישה רק לאוספים שצריכים אותה.
3. החליפו כל request.auth != null בבדיקת בעלות או בבדיקת תפקיד, אלא אם באמת כל משתמש מחובר אמור לראות הכול.
4. עשו את מבחן המשתמש השני. פתחו חשבון נוסף בחלון גלישה פרטית, ונסו לקרוא או לשנות נתונים של החשבון הראשון. אם זה עובד, עצרו.
5. הוסיפו כללים יחד עם כל אוסף חדש. בלשון פיירבייס, כללי האבטחה הם סכמה, ומוסיפים אותם כשמוסיפים מסמכים.
6. בדקו את הכללים באמולטור. פיירבייס ממליצה לבדוק אותם עם Firebase Local Emulator Suite, ולהוסיף את הבדיקות לתהליך הפריסה.
7. חפשו מפתחות סודיים בקוד הלקוח: Gemini, חשבון שירות, FCM ומפתחות של שירותים חיצוניים. כל אלה עוברים לשרת.
8. העבירו לשרת כל החלטה שנוגעת לכסף או להרשאות: מחירים, תפקידים, הנחות, וגישה לנתונים של אחרים.
9. הפעילו App Check בכל שירות שתומך בו. לפי התיעוד, הוא מאשר שהבקשה מגיעה מהאפליקציה שלכם, ומונע חלק מהניצול לרעה, אבל לא את כולו, ולא מחליף כללים.
10. הגדירו התראות תקציב. פיירבייס ממליצה עליהן כדי לדעת כשהשימוש חורג מהצפוי, וזה גם סימן מוקדם לניצול לרעה.
11. הפרידו בין פרויקט פיתוח לפרויקט ייצור, כדי שניסויים לא ייגעו בנתונים של משתמשים אמיתיים.
12. אם יש התחברות עם מייל וסיסמה, הפעילו את ההגנה מפני חשיפת כתובות מייל (email enumeration protection), שמופיעה ברשימה הרשמית.

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

שורה תחתונה

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

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

רוצים ללמוד לעבוד עם כלי AI בצורה מסודרת, עם תרגול בכל שיעור? יש סדרת קורסים אינטראקטיביים ב-9.90 שקלים, שמתאימה גם למי שבונה את האפליקציה הראשונה שלו.

מקורות

• פיירבייס: מפתחות API בפרויקטים (נבדק ב-2026-10-19)
• פיירבייס: הימנעות מכללים לא מאובטחים (נבדק ב-2026-10-19)
• פיירבייס: יסודות כללי האבטחה (נבדק ב-2026-10-19)
• פיירבייס: תחילת עבודה עם כללי אבטחה ב-Cloud Firestore (נבדק ב-2026-10-19)
• פיירבייס: מדריך התחלה ל-Cloud Firestore (נבדק ב-2026-10-19)
• פיירבייס: רשימת בדיקת אבטחה (נבדק ב-2026-10-19)
• פיירבייס: App Check (נבדק ב-2026-10-19)
• פיירבייס: אימות אסימוני זיהוי בשרת (נבדק ב-2026-10-19)
• סופהבייס: מפתחות API (נבדק ב-2026-10-19)
• OWASP Top 10:2025 (נבדק ב-2026-10-19)