Base44 מאובטחת? חולשות שדווחו, הרשאות גישה ומה לבדוק באפליקציה שלכם
חוקרים דיווחו על פגמים ב-Base44 עצמה, ולדבריהם העיקריים שבהם תוקנו. אבל רוב מה ששומר על הנתונים של אפליקציה הוא הגדרות שנמצאות בשליטת הבעלים שלה. הנה התקריות שדווחו, איך עובדות הרשאות הגישה ב-Base44, ורשימת בדיקות לאפליקציה שלכם.
עדכון אחרון: 7 דקות קריאהמאת צוות Unbase44
בעמוד הזה
בקצרה
Base44 בטוחה? לתשובה המועילה יש שני חלקים.
הפלטפורמה. חוקרי אבטחה דיווחו בפומבי על פגמים ב-Base44 עצמה, רובם ב-2025. המוכרים ביותר הגיעו מ-Wiz, שמצאה שאפשר להצטרף לאפליקציות פרטיות בעזרת מזהה האפליקציה הציבורי בלבד, ומ-Imperva, שמצאה דרכים לגנוב טוקנים של התחברות. בשני המקרים החוקרים אמרו ש-Base44 תיקנה את הבעיה, ו-Wiz אמרה שלא נמצאה עדות לכך שלקוח כלשהו נפגע. Base44 מצהירה שיש לה הסמכות SOC 2 Type II ו-ISO 27001, שהיא מריצה בדיקות חדירה ושיש לה תוכנית Bug Bounty.
האפליקציה שלכם. רוב מה שקובע אם הנתונים באפליקציה שלכם בטוחים נמצא בהגדרות שבשליטתכם: מי יכול לפתוח את האפליקציה, הרשאות הגישה של כל טבלה, האם פונקציות השרת בודקות מי פונה אליהן, איפה נמצאים מפתחות ה-API שלכם, ולמי יש הרשאות ניהול. התיעוד של Base44 עצמה אומר את זה במפורש: "אתם אחראים להגדרות האבטחה של האפליקציה שלכם."
העמוד הזה מפרט את התקריות שדווחו, עם תאריכים ומקורות, מסביר איך עובדות הרשאות הגישה ב-Base44, ונותן רשימת בדיקות לאפליקציה שלכם.
בעיות אבטחה שדווחו, עם תאריכים ומקורות
אלה הבעיות שחוקרי אבטחה וכלי תקשורת אמינים דיווחו עליהן בפומבי, נכון לאוקטובר 2026. כל שורה מתארת את מה שדווח, ולא יותר.
| פורסם | מי דיווח | מה דווח | התוצאה, לפי הדיווח |
|---|---|---|---|
| 29 ביולי 2025 | Wiz Research | נקודות קצה לא מתועדות של הרשמה ושל אימות אימייל אפשרו לכל מי שידע את ה-app_id של אפליקציה, ערך שמופיע בכתובות של האפליקציה ובקבצים ציבוריים, ליצור חשבון מאומת באפליקציה פרטית, ולעקוף את בקרות ההתחברות, כולל single sign-on. |
דווח ב-9 ביולי 2025 ותוקן בתוך 24 שעות. לדברי Wiz, לא נמצאה עדות לכך שלקוח כלשהו נפגע. |
| 27 באוגוסט 2025 | Imperva Threat Research | הפניה פתוחה (open redirect) בתהליך ההתחברות, שיכלה לשלוח את טוקן הגישה של משתמש לאתר אחר; XSS מאוחסן (stored cross-site scripting) ב-app.base44.com, שהתאפשר כי ההגבלה על עריכת קוד, יכולת פרימיום, נאכפה רק בדפדפן; וטוקן ההתחברות הראשי של Base44, שהועבר בכתובת ה-URL לאפליקציות שמשתמשים בנו. |
דווח במרץ 2025. לדברי Imperva, הספקית תיקנה את כל הבעיות: תיקונים חלקיים במרץ, ושינויים נוספים באפריל. |
| 31 באוגוסט 2025 | וואלה, בדיווח על מחקר של Dos-Op | חולשת NoSQL injection בבדיקות ההתחברות וההרשאות; לפי הדיווח, יותר מ-200 אפליקציות היו חשופות. | דווח ל-Base44 ב-22 באוגוסט 2025; Base44 פרסמה עדכון שלושה ימים אחר כך, והחוקרים אמרו שחלק מדפי הניהול עדיין היו נגישים. שנוי במחלוקת: Base44 אמרה שהבעיה נבעה מהגדרות של הלקוח, ובתגובה שפורסמה בגיקטיים אמרה שהחוקר הסיר בעצמו את כללי האבטחה של האפליקציה שלו. |
| 7 במאי 2026 | Security Boulevard, בדיווח על מחקר של RedAccess | כ-380,000 אפליקציות ונכסים אחרים, נגישים לציבור, שנבנו עם Lovable, Base44, Netlify ו-Replit; בכ-5,000 מהם היה מידע ארגוני רגיש. | לא פגם בפלטפורמה. החוקרים הצביעו על אפליקציות שנשארו נגישות לציבור, כשהגדרת הפרטיות נתונה בידי מי שבנה אותן. לא פורסם פילוח לפי פלטפורמה. |
באותה כתבה בגיקטיים, Base44 אמרה שהבעיות ש-Imperva מצאה התגלו ותוקנו במרץ 2025, כשהיו לה מעט משתמשים, ושהבעיה ש-Wiz מצאה השפיעה על פחות מ-3% מהאפליקציות.
שני דפוסים חוזרים בדיווחים האלה. הפגמים בפלטפורמה היו בהתחברות ובטיפול בטוקנים, ש-Base44 מפעילה ומתקנת באופן מרכזי. המחקר מ-2026, כמו המחלוקת סביב הממצאים של Dos-Op, עוסק באופן שבו הוגדרה כל אפליקציה בנפרד. החלק הזה באחריותכם.
במה Base44 מטפלת ברמת הפלטפורמה
לפי דף האבטחה וסקירת האבטחה של Base44, נכון לאוקטובר 2026:
- הסמכות SOC 2 Type II ו-ISO 27001, והסכם עיבוד נתונים (DPA) לפי בקשה, לצורכי GDPR.
- הצפנה בתעבורה (TLS 1.2 ומעלה) ובאחסון (AES-256). פרטי גישה שמורים מוצפנים באמצעות AWS Key Management Service, עם מפתח ש-Base44 מנהלת; לסביבות עבודה במסלול Enterprise אפשר לקבל מפתח ייעודי.
- בדיקות חדירה של צוותים פנימיים וחיצוניים, תוכנית Bug Bounty בהזמנה בלבד, וניטור אבטחה 24/7.
- הגבלת קצב (rate limiting) על כל נקודות הקצה הציבוריות.
באותו תיעוד מופיעות גם כמה מגבלות שכדאי להכיר:
- הנתונים לא מוצפנים מקצה לקצה; Base44 מציינת שאנשי הניהול שלה יכולים לגשת לנתונים שלכם במקרה הצורך.
- טוקני ההתחברות נשמרים ב-localStorage של הדפדפן. אין אפשרות לעוגיות HttpOnly.
- אין הגדרות CORS נפרדות לכל אפליקציה, ואי אפשר להגדיר לאפליקציה מסוימת כותרות כמו Content-Security-Policy ו-Strict-Transport-Security. אפשר לשלוט בהטמעה (embedding) ובהרשאות לתכונות של הדפדפן.
איך עובדות הרשאות הגישה ב-Base44
מי יכול לפתוח את האפליקציה
לכל אפליקציה יש הגדרת נראות אחת: Public (ציבורית: כל אחד באינטרנט), Private (פרטית: רק מי שהוזמן, עם התחברות) או Workspace (סביבת העבודה שלכם ב-Base44, עם התחברות). אפליקציות פרטיות דורשות מסלול בתשלום. אפליקציה ציבורית שלא דורשת התחברות לא יכולה להבחין בין מבקרים, ולכן כל טבלה שהיא יכולה לקרוא פתוחה לקריאה לכולם.
הרשאות גישה לנתונים (row level security)
לכל טבלה יש הרשאות ל-Create (יצירה), Read (קריאה), Update (עדכון) ו-Delete (מחיקה) (ניהול הרשאות לנתונים). בעורך, כל פעולה יכולה להשתמש בסוגי הכללים האלה:
| כלל | למי יש גישה |
|---|---|
| All Users (כל המשתמשים) | לכל אחד, גם בלי להתחבר |
| Creator Only (היוצר בלבד) | רק למי שיצר את הרשומה |
| Entity-User Field Comparison (השוואה בין שדה ברשומה למשתמש) | למשתמשים שהחשבון שלהם תואם לשדה ברשומה, למשל assigned_to = האימייל שלהם |
| User Property Check (בדיקת מאפיין של המשתמש) | למשתמשים שיש להם מאפיין מסוים בחשבון, למשל תפקיד Admin |
מספיק לעמוד באחד הכללים כדי לקבל גישה. Base44 מגדירה את הכללים אוטומטית בזמן שה-AI בונה את הטבלאות, ומציגה באנר Permission risks detected (זוהו סיכונים בהרשאות) כשהיא מזהה משהו פתוח מדי.
התיעוד למפתחים של Base44 מראה מה יש מתחת. הכללים שמורים בסכמה של כל טבלה בתור row level security (אבטחה ברמת השורה), ואפשר להוסיף field level security (אבטחה ברמת השדה) לשדות בודדים, כמו שכר. תנאים יכולים להשוות רשומה למשתמש המחובר:
"rls": {
"create": true,
"read": { "created_by": "{{user.email}}" },
"update": { "created_by": "{{user.email}}" },
"delete": { "user_condition": { "role": "admin" } }
}
קריאה שנדחית לא מחזירה כלום, כאילו הרשומות לא קיימות. כתיבה שנדחית נכשלת עם שגיאת הרשאה. חריג אחד חשוב: קוד בפונקציית שרת שמשתמש ב-service role של Base44 עוקף את הכללים האלה לגמרי, ולכן הפונקציה עצמה צריכה לבדוק מי פונה אליה.
מה לבדוק באפליקציה שלכם
עברו על הרשימה הזו בכל אפליקציה שמחזיקה מידע אישי או עסקי. סריקת האבטחה של Base44 מכסה כמה מהסעיפים, והיא חינמית בכל המסלולים.
- נראות. האפליקציה ציבורית כשהיא צריכה להיות פרטית, או מוגבלת לסביבת העבודה? כל אחד יכול למצוא ולפתוח אפליקציה ציבורית, והמחקר מ-2026 שתואר למעלה עסק באפליקציות שנשארו ציבוריות.
- ההרשאות של כל טבלה. חפשו All Users ב-Read בכל מה שאישי, כמו הזמנות, הודעות, טפסים שנשלחו או פרופילים של משתמשים. למידע אישי מתאים בדרך כלל Creator Only, או השוואת שדה. אחר כך התחברו בתפקידים שונים בתצוגה המקדימה (Preview), וודאו שכל תפקיד רואה רק את מה שמותר לו.
- ישויות (entities) ציבוריות. טפסי יצירת קשר וטבלאות הרשמה מאפשרים לא פעם לכל אחד לבצע Create. זה בסדר, כל עוד Read, Update ו-Delete מוגבלים לתפקיד ה-Admin שלכם.
- פונקציות שרת. הסריקה מסמנת פונקציות שמחזירות נתונים בלי לבדוק מי מחובר ("Anyone can run this function", כלומר כל אחד יכול להריץ את הפונקציה). שימו לב במיוחד לפונקציות שמשתמשות ב-service role, ודאגו שפונקציות שמטפלות ב-webhooks יאמתו את החתימה של השולח.
- מפתחות סודיים (secrets) בקוד של צד הלקוח. מפתח API שכתוב בתוך דף או רכיב גלוי לכל מבקר. שמרו את המפתחות כמפתחות סודיים ב-Base44, וקראו לשירותים חיצוניים מתוך פונקציות שרת; הבדיקה Exposed secrets (מפתחות חשופים) בסריקה מחפשת בדיוק את זה.
- יכולות שצורכות קרדיטים. הבדיקה Credit protection (הגנה על קרדיטים) בסריקה מסמנת יכולות AI, תמונות או אימייל שאפשר להפעיל מחוץ לאפליקציה, כך שמישהו אחר יכול לבזבז את הקרדיטים של האינטגרציות שלכם.
- תפקידי Admin ושותפי עריכה. Base44 מוסיפה שותפי עריכה (collaborators) לאפליקציה בתפקיד Admin כברירת מחדל, ובאפליקציות ציבוריות גם משתמשים בתפקיד User יכולים להזמין משתמשים אחרים. עברו על רשימת המשתמשים (Users), הסירו חשבונות שאתם לא מזהים, ושמרו את תפקיד ה-Admin למי שבאמת צריך אותו.
- הטמעה. אם יש באפליקציה התחברות או תשלומים, הגדירו את ההטמעה ל-No one (אף אחד), או ל-Only these sites (רק האתרים האלה) אם אתם מטמיעים אותה באתר שלכם.
הריצו את הסריקה שוב אחרי כל שינוי גדול, כמו טבלאות חדשות, אינטגרציות חדשות או הרשאות חדשות. סריקת חולשות בקוד והאינטגרציה האופציונלית עם Wiz דורשות מסלול Builder ומעלה.
מה משתנה כשמריצים את האפליקציה בעצמכם
העברת אפליקציה מ-Base44 לא הופכת אותה למאובטחת, וגם לא פחות מאובטחת, כשלעצמה. היא משנה מי אחראי על איזה חלק.
- הרשאות הגישה עוברות איתכם, כולל הטעויות. עם Unbase44, כל טבלה עוברת עם הרשאות הגישה שלה, וצד השרת התואם ל-Base44 אוכף אותן על השרת שלכם. טבלה שפתוחה לכולם ב-Base44 תהיה פתוחה לכולם גם אחרי ההעברה. תקנו קודם את ההרשאות.
- עבודת הפלטפורמה עוברת אליכם. ההסמכות, בדיקות החדירה, תוכנית ה-Bug Bounty והניטור 24/7 של Base44 מכסים את הפלטפורמה של Base44. הם לא מגיעים עם האחסון שלכם. בחשבונות שלכם, אתם, או מי שמפתח בשבילכם, מעדכנים את השרת ואת התלויות שלו, עוקבים אחרי הלוגים ומגיבים לבעיות. ספק האחסון אחראי על השכבה שלו.
- אפשר לראות ולשנות הכול. קוד השרת נמצא במאגר (repository) שלכם ב-GitHub, ברישיון MIT ועם תיעוד, כך שמפתחים או בודקי אבטחה יכולים לקרוא בדיוק איך עובדות ההתחברות ובדיקות הגישה.
- המפתחות שלכם נמצאים בחשבונות שלכם. המפתחות הסודיים נשמרים בסביבת האחסון שלכם, והאימייל וה-AI רצים על החשבונות שלכם אצל הספקים. אחרי ההעברה, "Revoke access" (בטלו גישה) בעמוד של האפליקציה ב-Unbase44 מוחק כל מפתח ש-Unbase44 החזיק.
- אתם בוחרים איפה הנתונים נמצאים. האזור הוא האזור שתבחרו לאחסון ולמסד הנתונים, וזה חשוב ל-GDPR ולמיקום הנתונים.
אם האפליקציה מטפלת במידע רפואי או במידע מפוקח אחר, הכללים מחמירים יותר בכל מקום שבו היא רצה. המדריך שלנו ל-HIPAA עוסק במקרה הזה.
שאלות ותשובות
Base44 בטוחה לשימוש?
Base44 מצהירה שיש לה הסמכות SOC 2 Type II ו-ISO 27001, שהיא מצפינה נתונים בתעבורה ובאחסון, ושהיא מריצה בדיקות חדירה ותוכנית Bug Bounty. הפגמים שחוקרים דיווחו עליהם ב-2025 תוקנו, לפי אותם חוקרים. אם האפליקציה שלכם בטוחה, זה תלוי בעיקר בנראות שלה, בהרשאות הגישה, בפונקציות השרת ובמקום שבו נמצאים מפתחות ה-API שלה, ואת כל אלה Base44 מגדירה כאחריות שלכם.
Base44 נפרצה אי פעם?
חוקרים דיווחו על חולשות בפלטפורמה, וכל אחת מהן דווחה כמתוקנת. Wiz דיווחה ביולי 2025 שאפשר היה להצטרף לאפליקציות פרטיות בעזרת מזהה האפליקציה בלבד; הפגם תוקן בתוך 24 שעות, ולדברי Wiz לא נמצאה עדות לכך שלקוח כלשהו נפגע. Imperva דיווחה באוגוסט 2025 על פגמים שאפשרו לגנוב טוקנים, ולדבריה הם תוקנו. בנפרד, מחקר שפורסם במאי 2026 מצא אפליקציות שנבנו בכמה בוני אפליקציות, ובהם Base44, שנשארו נגישות לציבור, כשיש בהן מידע רגיש.
יש ל-Base44 אבטחה ברמת השורה (row level security)?
כן. לכל טבלה יש הרשאות ליצירה, לקריאה, לעדכון ולמחיקה, כמו "היוצר בלבד" או "מנהלים בלבד", והתיעוד למפתחים של Base44 מתאר גם כללים ברמת השדה, לשדות בודדים. פונקציות שרת שמשתמשות ב-service role עוקפות את הכללים האלה, ולכן הן צריכות בדיקות משלהן.
מפתחות ה-API שלכם בטוחים ב-Base44?
לפי התיעוד של Base44, מפתחות שנשמרים בה כמפתחות סודיים מוצפנים, ואפשר להגיע אליהם רק מפונקציות שרת. מפתח שנכתב בקוד של צד הלקוח גלוי לכל מי שפותח את האפליקציה. סריקת האבטחה בודקת אם יש מפתחות חשופים.
העברה מ-Base44 הופכת את האפליקציה למאובטחת יותר?
לא, לא כשלעצמה. הרשאות הגישה עוברות עם האפליקציה, כולל הטעויות, ועבודת האבטחה ש-Base44 עושה ברמת הפלטפורמה עוברת אליכם או לספק האחסון. מה שמרוויחים הוא שליטה: הקוד, המפתחות ומיקום הנתונים פתוחים לבדיקה שלכם, וההחלטות עליהם שלכם.
מקורות
נבדק בתאריך 4 באוקטובר 2026. Base44 משתנה מהר; אם משהו כאן כבר לא מעודכן, נשמח לדעת.
- Wiz Research: חולשה קריטית ב-Base44 (29 ביולי 2025)
- Imperva: פגמים קריטיים ב-Base44 (27 באוגוסט 2025)
- וואלה: הממצאים של Dos-Op (31 באוגוסט 2025, בעברית)
- גיקטיים: ממצאי החוקרים ותגובת Base44 (1 בספטמבר 2025, בעברית)
- Security Boulevard: המחקר של RedAccess על אפליקציות שנבנו ב-vibe coding (7 במאי 2026)
- דף האבטחה של Base44 (הסמכות, הצפנה, בדיקות, ספקי משנה)
- סקירת האבטחה של Base44 (יכולות הפלטפורמה, טוקנים, כותרות, CORS, מפתחות הצפנה)
- מי יכול לגשת לאפליקציה (נראות, תפקידים, שותפי עריכה)
- ניהול הרשאות לנתונים (סוגי כללים)
- אבטחת ישויות: כללים ברמת השורה וברמת השדה, service role
- הרצת סריקת אבטחה (בדיקות, דרישות מסלול, הערה על הצפנה)