תשובה קצרה: בודקים אבטחה של אפליקציה שנבנתה ב-Base44 בתשע בדיקות: מי יכול לפתוח את האפליקציה, מי מוגדר מנהל, כללי RLS על כל entity, כללי FLS על שדות רגישים, ניסיון אמיתי עם שני משתמשים, כללים שנשענים על שדות שהמשתמש יכול לשנות לעצמו, שימוש ב-asServiceRole בפונקציות backend, איפה יושבים המפתחות, ואיך מאומתים תשלומים. Base44 אחראית על התשתית, וכל ההגדרות ברשימה הזו הן שלכם. את רובן אפשר לבדוק לבד בכמה שעות.
אם הגעתם לכאן בעקבות הפרצה שחשפה Wiz ביולי 2025, הסיפור המלא שלה נמצא באבטחה ב-Base44: מה קרה בפרצה. המדריך הזה הוא רשימת הבדיקה המלאה לפני שמשתמשים אמיתיים נכנסים לאפליקציה.
במה בדיקת אבטחה ב-Base44 שונה מבדיקה ב-Supabase?
ב-Base44 לא כותבים מדיניות SQL. הנתונים יושבים ב-entities שמוגדרים ב-JSON Schema, וההרשאות נכתבות בתוך הסכמה: כללי RLS ברמת ה-entity וכללי FLS ברמת השדה (תיעוד Base44). לכל אחת מהפעולות create, read, update ו-delete נותנים ערך: true (כולם), false (אף אחד), או תנאי שמשווה שדה ברשומה לנתוני המשתמש המחובר, למשל created_by מול האימייל שלו.
היתרון: כל ההרשאות כתובות במקום אחד שאפשר לקרוא. המלכודת: לא מצאנו בתיעוד הגדרה של מה קורה ל-entity שלא נכתבו לו כללים, ולכן אל תניחו ברירת מחדל. בדקו בפועל. רקע על הפלטפורמה עצמה נמצא במילון: Base44.
מי יכול לפתוח את האפליקציה בכלל?
1. נראות האפליקציה ו-Require login
לפי מדריך ניהול הגישה של Base44, לאפליקציה יש שלוש רמות נראות: Public (כל מי שיש לו קישור), Workspace (חברי סביבת העבודה, עם התחברות) ו-Private (רק מוזמנים, עם התחברות). באפליקציה ציבורית אפשר לדרוש התחברות עם Require login to access.
איך בודקים: בדקו את ההגדרה, ואז פתחו את האפליקציה בחלון גלישה בסתר.
איך נראה רע: אפליקציה עם נתוני לקוחות שמוגדרת Public בלי Require login, או מסכים שמציגים נתונים לפני התחברות. וזכרו ש-Require login מוודא רק שיש משתמש מחובר. באפליקציה ציבורית כל מי שנרשם הוא משתמש, ומה שהוא רואה נקבע בבדיקות 3 עד 6.
2. מי מוגדר admin
לאפליקציה יש שני תפקידים מובנים: admin ו-user. מנהל ניגש לאזורים שמוגבלים למנהלים.
איך בודקים: עברו על רשימת המשתמשים וסננו לפי תפקיד admin.
איך נראה רע: חשבונות בדיקה, פרילנסר שסיים לעבוד, כתובת של עובד שעזב. ובנוסף: מסך ניהול שמוסתר בממשק, כשה-entity שמאחוריו פתוח לכל משתמש. כפתור מוסתר לא מגביל בקשה שנשלחת ישירות.
איך בודקים את כללי הגישה לנתונים?
3. כלל RLS לכל entity ולכל פעולה
איך בודקים: עברו entity אחרי entity ורשמו בטבלה את ארבעת הערכים: create, read, update, delete.
איך נראה רע: read: true על entity שמחזיק מידע אישי, הזמנות או הודעות. update: true או delete: true כמעט אף פעם לא נכונים. entity בלי כללים בכלל. באחד הפרויקטים שטיפלנו בהם, מערכת פינטק שנבנתה ב-Base44, כללי ה-RLS היו חסרים דווקא על טבלאות התשלומים.
4. FLS על שדות רגישים
FLS (Field Level Security) מגביל קריאה וכתיבה של שדה בודד. הוא נחוץ כשמשתמש צריך לראות או לערוך רשומה, אבל לא את כל השדות שלה.
איך בודקים: לכל entity שהבעלים יכול לעדכן, חפשו שדות שקובעים כסף, הרשאה או מצב: status, price, approved, credits, plan.
איך נראה רע: ל-entity יש כלל update שמתיר לבעלים, ואין FLS על השדות האלה. המשמעות: משתמש יכול לאשר לעצמו בקשה, לשנות מחיר של הזמנה או להוסיף לעצמו קרדיטים.
5. בדיקת שני המשתמשים, בפועל
קריאת הכללים לא מספיקה, כי תנאי שנראה נכון יכול להשוות לשדה הלא נכון.
איך בודקים: פתחו שני חשבונות בדיקה, A ו-B, וצרו בכל אחד כמה רשומות. התחברו כ-A, פתחו את לשונית Network בכלי הפיתוח, ומצאו את הבקשות שמכילות את שם ה-entity. שלחו אותן שוב עם המזהה של רשומה של B, ונסו גם עדכון ומחיקה של רשומה של B. פירוט נוסף של התהליך נמצא במילון: אודיט אבטחה ל-Base44.
איך נראה רע: כל רשומה של B שחוזרת, משתנה או נמחקת.
6. כללים שנשענים על שדות שהמשתמש יכול לשנות לעצמו
תנאי RLS יכולים להשתמש בנתונים של המשתמש המחובר, למשל שדה מותאם בשם company_id שמפריד בין לקוחות עסקיים. לפי תיעוד ה-SDK של Base44, הפעולה updateMe מאפשרת למשתמש המחובר לעדכן כל שדה מותאם שהוגדר ב-entity של המשתמש. שינוי תפקיד דורש הרשאת עריכה באפליקציה.
איך בודקים: חפשו בכללים התייחסות ל-user.data. לכל שדה כזה, התחברו כמשתמש רגיל ונסו לשנות אותו לערך של לקוח אחר, למשל דרך מסך עריכת הפרופיל ושליחה חוזרת של הבקשה מלשונית Network עם הערך החדש.
איך נראה רע: השינוי עבר, ועכשיו המשתמש רואה את הנתונים של הלקוח האחר. זה כשל ההפרדה בין לקוחות במערכת multi-tenant, והוא מהממצאים החמורים ביותר שאפשר למצוא לפני השקה. אם יש באפליקציה שכבה שחוסמת את השינוי, הבדיקה תראה לכם את זה.
איפה הקוד בצד השרת עוקף את הכללים?
7. asServiceRole בפונקציות backend
לפי תיעוד האבטחה של Base44, base44.asServiceRole זמין בפונקציות backend שרצות ב-Base44 ועוקף לגמרי את כללי ה-RLS וה-FLS, בלי קשר להגדרות של ה-entity. זה נחוץ לפעולות ניהול, וזה גם אומר שכל פונקציה שמשתמשת בו צריכה לבדוק בעצמה מי קרא לה ומה מותר לו.
איך בודקים: חפשו asServiceRole בקוד הפונקציות. לכל מופע, ודאו שלפניו הפונקציה מזהה את המשתמש ובודקת שהרשומה שייכת לו. אחר כך קראו לפונקציה כמשתמש B עם מזהים של A.
איך נראה רע: פונקציה שמקבלת מזהה רשומה מהבקשה, ומחזירה או מעדכנת אותה עם asServiceRole בלי בדיקת בעלות. פונקציה כזו מבטלת את כל הכללים שהוגדרו בבדיקות 3 עד 6.
8. מפתחות וסודות
ב-Base44 סודות נשמרים בהגדרות האפליקציה וזמינים לפונקציות ה-backend בזמן ריצה (תיעוד Base44). מפתחות של Stripe, OpenAI או שירות מיילים צריכים לשבת שם.
איך בודקים: באתר החי, בכלי הפיתוח, לחצו Ctrl+Shift+F וחפשו sk_live, sk-, api_key ו-secret. או הריצו את בדיקת האבטחה לאתר, שקוראת את הקוד שהאתר מגיש ומדווחת על מפתחות שדלפו. אם סנכרנתם את הקוד ל-GitHub, חפשו גם בהיסטוריה.
איך נראה רע: כל מפתח סודי בקוד צד-לקוח. צריך להחליף אותו אצל הספק, כי מחיקה מהקוד לא מבטלת מפתח שכבר נחשף. באחד הפרויקטים שטיפלנו בהם, מפתחות API בצד הלקוח היו אחד מחמשת הממצאים הקריטיים.
איך מוודאים שתשלומים לא נפתחים מבחוץ?
9. webhook מאומת, חד-פעמי, ושדה תשלום שהמשתמש לא יכול לשנות
ב-Base44 ה-webhook של ספק התשלומים הוא פונקציית backend. לפי התיעוד של Stripe, צריך לאמת את החתימה של כל אירוע, ואותו אירוע עלול להגיע יותר מפעם אחת, ולכן שומרים את מזהי האירועים שעובדו ומדלגים על כפולים.
איך בודקים: בקוד הפונקציה חפשו אימות חתימה עם סוד שמתחיל ב-whsec_, ו-entity שבו נשמרים מזהי האירועים. בסביבת בדיקה שלחו את אותו אירוע פעמיים עם כפתור Resend בלוח של Stripe. ובדקו מי יכול לכתוב לשדה שמסמן שמשתמש שילם.
איך נראה רע: פונקציה שסומכת על גוף הבקשה בלי חתימה, הזמנה כפולה אחרי שליחה חוזרת, או שדה is_paid או plan שהמשתמש יכול לעדכן לעצמו. תקלות נפוצות ב-webhooks מפורטות במדריך ל-webhooks של Stripe שלא עובדים.
מה עם סריקת האבטחה של Base44?
לפי מדריך ניהול הגישה, Base44 מציעה Run Security Scan לאפליקציות ציבוריות לפני שמשתפים אותן. הריצו אותה. היא לא יודעת את כללי העסק שלכם: אילו לקוחות צריכים להיות מופרדים, מי אמור לאשר מה, ואיזה שדה קובע כסף. בדיקות 5, 6 ו-7 דורשות לדעת מה התכוונתם שיקרה.
הצ'קליסט בטבלה אחת
| # | בדיקה | איך בודקים | איך נראה רע |
|---|---|---|---|
| 1 | נראות והתחברות | הגדרות גישה וחלון בסתר | Public בלי login עם נתוני לקוחות |
| 2 | מנהלים | סינון משתמשים לפי admin | חשבונות ישנים, מסך ניהול מוסתר בלבד |
| 3 | RLS לכל entity | טבלה של ארבע פעולות | read או update פתוחים לכולם |
| 4 | FLS | שדות כסף, הרשאה ומצב | משתמש משנה status או credits |
| 5 | שני משתמשים | בקשה חוזרת מ-Network | רשומה של משתמש אחר חוזרת |
| 6 | שדות שהמשתמש משנה | עדכון company_id לעצמכם | רואים נתונים של לקוח אחר |
| 7 | asServiceRole | חיפוש בקוד הפונקציות | אין בדיקת בעלות לפני השימוש |
| 8 | סודות | חיפוש בקוד האתר החי | מפתח סודי בדפדפן |
| 9 | תשלומים | Resend ובדיקת שדה התשלום | אין חתימה, כפילות, is_paid פתוח |
מה נשאר מחוץ לרשימה?
הרשימה מכסה הרשאות וסודות. היא לא בודקת אם יש תיעוד של מי שינה מה (audit log), אם אפשר לייצא ולשחזר את הנתונים, איך האפליקציה מתנהגת תחת עומס, ומה יעלה האירוח כשהשימוש יגדל. באחד הפרויקטים שטיפלנו בהם, מערכת פינטק על Base44 לפני סבב Series A, הבדיקה מצאה 23 ממצאים, ביניהם מפתחות API בצד הלקוח, RLS חסר על טבלאות התשלומים והיעדר audit logs. אם אתם שוקלים לצאת מהפלטפורמה, המדריך למעבר מ-Base44 ל-Supabase מפרט מה עובר ומה צריך לבנות מחדש.
את החלקים האלה מכסה בדיקה לפני השקה: מהנדס עובר על האבטחה וההרשאות, מבנה הנתונים והעומס, התשלומים ועלות האירוח, לפי ארבעת השלבים של ה-Audit Framework, ומוסר דוח בעברית עם תיקונים מדורגים לפי עדיפות וטווח עלות לכל תיקון, ושיחת מעבר של 45 דקות. כך נראה דוח לדוגמה.
מקורות
- Base44 Docs - Entity security (RLS and FLS): תחביר הכללים ו-asServiceRole
- Base44 Docs - Managing access: רמות נראות, תפקידים וסריקת האבטחה
- Base44 SDK - auth: מה updateMe מאפשר למשתמש לעדכן
- Base44 CLI - secrets set: סודות לפונקציות backend
- Stripe Docs - Receive Stripe events in your webhook endpoint: אירועים כפולים ואימות חתימה
רוצים לדעת אם האפליקציה מוכנה? בעמוד הבדיקה לפני השקה אפשר לקבוע שיחת וואטסאפ חינמית של 20 דקות. מספרים מה בניתם ב-Base44 ומי ישתמש בזה, ונגיד לכם אם צריך בדיקה מלאה או שהרשימה הזו מספיקה.
