אפליקציה מ-Base44 או Lovable: מה לבדוק לפני השקה

קודם כל: הכלים האלה טובים

Base44 היא חברה ישראלית שהקים Maor Shlomo, ונקנתה על ידי Wix ביוני 2025 בתשלום ראשוני של כ-80 מיליון דולר. Lovable צמחה באותה תקופה לאחד הכלים הפופולריים לבניית אפליקציות מפרומפט. שניהם עושים משהו שלפני שלוש שנים נשמע כמו מדע בדיוני: יזם בלי רקע טכני מתאר מה הוא רוצה ומקבל אפליקציה עובדת עם מסד נתונים והתחברות.

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

שני סוגי סיכון, ורק אחד מהם שלכם

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

Base44, יולי 2025. חוקרי Wiz גילו שאפשר היה להירשם לאפליקציה פרטית, כולל כזו שמוגדרת ל-SSO בלבד, בעזרת מזהה האפליקציה בלבד. המזהה הזה לא סודי: הוא מופיע בכתובת ובקובץ ה-manifest. הדיווח נשלח ב-9 ביולי 2025, התיקון עלה תוך פחות מ-24 שעות, ולפי Wix לא נמצאה עדות לניצול. זה היה באג פלטפורמה, והספק טיפל בו כמו שצריך.
Base44, ממצאי Imperva. חוקר מ-Imperva דיווח לחברה במרץ 2025 על שרשרת בעיות, בהן הפניה פתוחה בתהליך ההתחברות שאפשרה להעביר טוקן גישה לדומיין חיצוני. הממצאים פורסמו באוגוסט 2025, אחרי שהחברה טיפלה בהם. שוב, אחריות הספק.
Lovable, CVE-2025-48757. כאן הסיפור שונה. החולשה מתוארת כמדיניות RLS לא מספקת במסדי הנתונים של אפליקציות שנבנו בכלי, מה שאפשר גישה לא מאומתת לטבלאות. היא קיבלה ציון CVSS של 9.3, ו-Lovable חולקת על הרישום בנימוק שכל לקוח אחראי להגנה על המידע של האפליקציה שלו. בין אם מסכימים ובין אם לא, הנימוק הזה הוא בדיוק הנקודה: הספק אומר במפורש שזה עליכם.
Lovable, אפריל 2026. לפי Lovable עצמה, בין 3 בפברואר ל-20 באפריל 2026 היסטוריית הצ'אט וקוד המקור של פרויקטים ציבוריים היו נגישים לכל משתמש מחובר שהחזיק קישור לפרויקט, בעקבות רגרסיה בצד השרת. התיקון עלה תוך שעתיים. הלקח המעשי: כל מפתח API שהדבקתם פעם בצ'אט עם הכלי צריך להיחשב חשוף ולהתחלף.

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

עשר בדיקות לפני השקה

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

1. סודות בקוד שרץ בדפדפן

כל מה שהדפדפן מקבל, כל אחד יכול לקרוא. פתחו את האפליקציה, לחצו F12, ובלשונית Sources חפשו מחרוזות כמו sk_, secret, service_role או מפתח של ספק AI. מפתח ה-anon או ה-publishable של Supabase נועד להיות ציבורי. מפתח service_role לא, כי הוא עוקף את כל ההרשאות. מפתח של OpenAI או Anthropic בצד הלקוח פירושו שמישהו אחר יכול לשרוף את התקציב שלכם.

2. RLS בכל טבלה

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

3. בדיקת בעלות בכל שאילתה

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

4. בדיקת שני חשבונות

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

5. מי יכול להירשם

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

6. הגבלת קצב

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

7. גיבוי ששוחזר בפועל

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

8. לוגים והתראות

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

9. כסף

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

10. פרטיות

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

הרשימה בטבלה אחת

בדיקה	איך בודקים	מי יכול לבדוק	חוסם השקה?
סודות בקוד הלקוח	חיפוש בלשונית Sources בדפדפן	יזם, 15 דקות	כן
RLS בכל טבלה	לוח הבקרה של Supabase, מעבר על כל טבלה ומדיניות	יזם עם הדרכה	כן
בעלות בכל שאילתה	החלפת מזהים בכתובת ובבקשות	מפתח	כן
שני חשבונות	יצירה בחשבון א', ניסיון גישה מחשבון ב'	יזם, שעה	כן
הרשמה עצמית	ניסיון הרשמה מבחוץ לאפליקציה פרטית	יזם	כן, באפליקציה פרטית
הגבלת קצב	ניסיונות התחברות חוזרים, בדיקת הגדרות	מפתח	לא, אבל דחוף
גיבוי ושחזור	שחזור אחד לסביבה נפרדת	מפתח	כן, כשיש מידע לקוחות
לוגים והתראות	יצירת שגיאה מכוונת ובדיקה שההתראה הגיעה	מפתח	לא, אבל בשבוע הראשון
תשלומים	בדיקה שהמחיר והאישור מגיעים מהשרת	מפתח	כן
פרטיות	מיפוי המידע שנאסף והגישה אליו	יזם עם יועץ	תלוי ברגישות המידע

להשאיר, להקשיח או לבנות מחדש

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

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

איך נראית העברה ממפתח

אם החלטתם להעביר את האפליקציה מ-Base44 או מ-Lovable למפתח או לסטודיו, הכנה טובה חוסכת שבוע עבודה:

גישה לקוד. שתי הפלטפורמות מאפשרות לחבר את הפרויקט ל-GitHub. ב-Base44, לפי התיעוד, סנכרון דו-כיווני דורש תוכנית Builder ומעלה. ב-Lovable הסנכרון דו-כיווני מול ענף אחד. חברו את זה לחשבון GitHub שלכם, לא של מישהו אחר.
מה לא עובר עם הקוד. מסד הנתונים, המשתמשים והקבצים לא נמצאים בריפו. ב-Base44 גם מבנה הנתונים, ההזדהות והפונקציות בצד השרת רצים על התשתית של הפלטפורמה, כך שיציאה ממנה פירושה להחליף את השכבה הזו.
רשימת שירותים ומפתחות. כל ספק שהאפליקציה מדברת איתו, מי מחזיק את החשבון, ואיזה מפתח בשימוש. מפתחות שהודבקו בצ'אט עם הכלי מחליפים לפני ההעברה.
היסטוריית הפרומפטים. נשמע מוזר, אבל זה האפיון הכי מדויק שיש לכם. הוא מספר מה ניסיתם, מה עבד ומה ויתרתם עליו.

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

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

שורה תחתונה

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

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

מקורות

המאמר נערך על ידי אביתר אדלר, CTO ב-FlowDev.

שאלות נפוצות

האם Base44 מאובטח?

הפלטפורמה עצמה מתוחזקת ברצינות: כשחוקרי Wiz דיווחו ב-9 ביולי 2025 על פרצה שאפשרה הרשמה לאפליקציות פרטיות, היא תוקנה תוך פחות מ-24 שעות, ולפי Wix לא נמצאה עדות לניצול. אבל אבטחת הפלטפורמה היא רק חצי מהתמונה. החצי השני הוא איך האפליקציה שלכם בנויה: מי רשאי לראות איזו רשומה, אילו מפתחות חשופים, ומה קורה כשמישהו מנסה לנחש מזהה. את החצי הזה אתם צריכים לבדוק בעצמכם.

מה זה RLS ולמה זה כל כך חשוב באפליקציה של Lovable?

RLS, או Row Level Security, הוא מנגנון ב-Postgres שקובע ברמת מסד הנתונים איזו שורה כל משתמש רשאי לקרוא ולכתוב. באפליקציות Lovable שמחוברות ל-Supabase, הדפדפן מדבר ישירות עם מסד הנתונים באמצעות מפתח ציבורי, כך ש-RLS הוא לעיתים קרובות ההגנה היחידה. לפי התיעוד של Supabase, טבלה בסכמה חשופה בלי RLS ניתנת לקריאה ולכתיבה על ידי כל תפקיד שיש לו הרשאה עליה.

אפשר להעביר אפליקציה מ-Base44 למפתח?

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

בניתי אפליקציה עם AI. מה עכשיו?

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

כמה עולה להעביר אפליקציה שנבנתה ב-vibe coding לפיתוח מקצועי?

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

בניתם אפליקציה ב-Base44 או Lovable? מה חייבים לבדוק לפני שמשיקים ללקוחות אמיתיים