מה קרה בפועל
ביולי 2025 פרסמה חברת המחקר Wiz ממצא על פלטפורמת ה-Vibe Coding הישראלית Base44, שנרכשה זמן קצר קודם לכן על ידי Wix: שתי נקודות קצה לא מתועדות לרישום ולאימות משתמשים היו חשופות ללא אימות, ואפשרו לכל גורם ליצור חשבון מאומת באפליקציות פרטיות - כולל כאלה שהוגדרו לגישה דרך SSO בלבד.
Wiz דיווחה לפלטפורמה ב-9 ביולי 2025. התיקון אומת למחרת, ב-10 ביולי, והאירוע נסגר רשמית ב-13 ביולי. הפרסום הפומבי היה ב-29 ביולי. Wix מסרה שהפרצה תוקנה תוך 24 שעות מרגע הדיווח ושלא נמצאה עדות לניצול שלה.
זה אירוע סגור. הסיבה שהוא עדיין רלוונטי היא לא הפרצה עצמה, אלא מה שהיא ממחישה על ההבדל בין אפליקציה שעובדת לאפליקציה שמוכנה לפרודקשן.
הפרט הטכני שחשוב להבין
הפגיעות לא דרשה כלי תקיפה, לא סיסמה ולא הרשאה. היא דרשה ערך אחד: app_id - מזהה האפליקציה, שאינו סוד.
שתי נקודות הקצה שהיו חשופות:
api/apps/{app_id}/auth/register
api/apps/{app_id}/auth/verify-otp
שליחת בקשה אליהן עם app_id תקין הספיקה כדי לייצר חשבון מאומת - ובכך לעקוף לחלוטין את מנגנון ההזדהות שהאפליקציה הגדירה.
ואת ה-app_id עצמו לא היה קשה למצוא. Wiz הראתה שהוא מופיע בנתיב קובץ ה-manifest של כל אפליקציה (manifests/{app_id}/manifest.json), וכי אפליקציות ארגוניות עם דומיין מותאם היו ניתנות לזיהוי דרך רשומת CNAME שהצביעה על base44.onrender.com.
זהו הדפוס הקלאסי של הסתמכות על ערך שאינו סוד כאילו הוא סוד. הוא לא ייחודי ל-Base44 ולא ייחודי לפלטפורמות AI, אבל הוא נפוץ במיוחד בקוד שנוצר במהירות, כי הוא לא נראה כמו באג - הכל עובד, עד שמישהו מנסה משהו שלא חשבתם עליו.
מה זה אומר על האפליקציה שלכם
זו הנקודה שבה כדאי להפריד בין שני דברים שמתערבבים בדיון הזה כל הזמן.
האחריות של הפלטפורמה היא התשתית: נקודות הקצה שלה, מנגנוני ההזדהות שלה, הבידוד בין לקוחות. הפרצה שנסגרה שייכת לקטגוריה הזו, וכשהיא נסגרת - היא נסגרת עבור כולם בבת אחת, בלי שתצטרכו לעשות דבר.
האחריות שלכם היא כל מה שהגדרתם בתוך האפליקציה: אילו טבלאות מוגנות ב-RLS ואילו נשארו פתוחות, אילו מפתחות נשלחים לדפדפן, מי יכול לקרוא מה. שום תיקון מצד הפלטפורמה לא נוגע בשכבה הזו.
מניסיון החילוץ שלנו, החשיפות שאנחנו מוצאים בפועל כמעט תמיד יושבות בשכבה השנייה. הפרצה בפלטפורמה היא אירוע נדיר שמישהו אחר מתקן; טבלה בלי RLS היא ברירת מחדל שקטה שממתינה שמישהו יבחין בה.
שלוש הבדיקות שמכסות את רוב החשיפה
אלה הבדיקות שאנחנו מריצים ראשונות בכל סריקת אבטחה לקוד AI, והן מכסות את הרוב המכריע של מה שאנחנו מוצאים.
1. RLS על כל טבלה, לא על חלקן
Row Level Security הוא המנגנון שמונע ממשתמש אחד לקרוא את הנתונים של משתמש אחר. הכשל הנפוץ אינו שכחה מוחלטת שלו, אלא הפעלה חלקית - RLS על טבלת המשתמשים, אבל לא על טבלת ההזמנות שמצביעה עליה.
בדקו כל טבלה שמכילה מידע של משתמשים, לא רק את הברורות. המדריך המלא עם דוגמאות SQL נמצא במדריך RLS ל-Supabase ו-Base44.
2. service_role לא נמצא בקוד צד-לקוח
מפתח service_role עוקף את כל מדיניות ה-RLS שהגדרתם - זו מטרתו. אם הוא הגיע לקוד שנשלח לדפדפן, כל ההגנה שבנתם בטלה, ומי שפותח את כלי הפיתוח יכול לראות אותו.
חפשו אותו בכל קוד הצד-לקוח, וגם בהיסטוריית ה-git. מפתח שנמחק מהקוד אבל נשאר בקומיט ישן הוא עדיין מפתח שדלף, וצריך לבטל אותו ולא רק למחוק.
3. נסו לגשת לנתונים של מישהו אחר
הבדיקה הכי פשוטה והכי חושפנית: פתחו שני חשבונות בדיקה, והתחברו לאחד מהם. נסו לגשת למזהה של רשומה ששייכת לשני - דרך כתובת URL, דרך קריאת API, דרך כל מקום שמקבל מזהה מבחוץ.
אם קיבלתם נתונים - יש לכם בעיה, והיא לא תיאורטית. זו בדיוק אותה משפחת כשלים שהפרצה ב-Base44 השתייכה אליה: ערך מזהה שהמערכת מתייחסת אליו כאילו הוא הרשאה.
מתי זה מצדיק ביקורת חיצונית
לא כל אפליקציה צריכה אודיט. שלושת התנאים שמצדיקים אותו לדעתנו:
- המערכת מחזיקה מידע אישי של אנשים אחרים - לקוחות, עובדים, מטופלים, מועמדים. כאן העלות של טעות אינה טכנית אלא רגולטורית ומוניטינית.
- לקוח, משקיע או גורם רכש שאל אתכם על אבטחה ואין לכם תשובה מבוססת. "בנינו ב-Base44 והם מטפלים באבטחה" אינה תשובה מספקת, כפי שההפרדה למעלה מסבירה.
- אתם שוקלים לצאת מהפלטפורמה - זה הרגע לדעת מה בדיוק אתם לוקחים אתכם. ראו מדריך המעבר מ-Base44 ל-Supabase.
אם אתם רוצים להתחיל לבד, בדיקת המוכנות לפרודקשן עוברת על 30 בדיקות הנדסיות ונותנת ציון ורשימת פערים, בלי למסור גישה לקוד.
שאלות נפוצות
האם האפליקציה שלי ב-Base44 נפרצה?
ככל הנראה לא. Wix מסרה שלא נמצאה עדות לניצול של הפרצה לפני שתוקנה, והתיקון הושלם תוך 24 שעות מרגע הדיווח. חשוב להבין את גבולות ההצהרה הזו: היא אומרת שלא נמצאה עדות לניצול, לא שאין דרך אחרת להיכנס לאפליקציה שלכם. הרשאות שהגדרתם בעצמכם, מפתחות שנחשפו בקוד צד-לקוח וטבלאות בלי RLS הם באחריותכם ולא הושפעו מהתיקון של Wix.
האם Base44 בטוחה לשימוש היום?
הפרצה הספציפית שנחשפה נסגרה ואומתה על ידי Wiz. אירוע כזה בפלטפורמה בוגרת - שמדווח, נסגר תוך 24 שעות ומפורסם בשקיפות - הוא סימן טוב יותר מפלטפורמה שמעולם לא דיווחה על כלום. הסיכון האמיתי ברוב הפרויקטים שאנחנו רואים אינו בפלטפורמה אלא בהגדרות שהמשתמש עצמו קבע בתוכה.
איך אני בודק לבד את האבטחה של האפליקציה שלי?
שלוש הבדיקות שבסעיף הקודם מכסות את רוב החשיפות שאנחנו מוצאים בפועל: לוודא ש-RLS מופעל על כל טבלה שמכילה מידע של משתמשים ולא רק על חלקן, לוודא שמפתח service_role לא מופיע בשום מקום בקוד שנשלח לדפדפן, ולנסות לגשת לנתונים של משתמש אחר מחשבון בדיקה.
האם Base44 תומכת בעברית?
כן. הממשק והתיעוד זמינים בעברית, והפלטפורמה נבנתה בישראל ונרכשה על ידי Wix. זו גם הסיבה שחלק ניכר מהאפליקציות שנבנו עליה שייכות לעסקים ישראלים, ושאירוע אבטחה בפלטפורמה הזו נוגע לשוק המקומי יותר מאשר אירוע מקביל בפלטפורמה אמריקאית.
למי פונים כשצריך עזרה עם Base44?
לתמיכה בפלטפורמה עצמה - דרך ערוצי התמיכה של Base44. לשאלות שנוגעות לקוד, לארכיטקטורה או לאבטחה של האפליקציה שבניתם - אלה באחריותכם ולא באחריות הפלטפורמה, וכאן נכנס מפתח או צוות הנדסי חיצוני.
מקורות
- Wiz Research - Critical Vulnerability in Base44 - הדיווח המקורי, כולל נקודות הקצה והציר הזמן
- SecurityWeek - Flaw in Vibe Coding Platform Base44 Exposed Private Enterprise Applications - 30 ביולי 2025
- Calcalist ctech - Wiz finds major security flaw in Base44, one month after Wix acquisition
בנית אפליקציה על Base44 או Lovable ואתם לא בטוחים מה חשוף? דברו איתנו בוואטסאפ - נעבור על שלוש הבדיקות למעלה יחד, בלי גישה לקוד.
