דלגו לתוכן
agentical

האם המידע של הלקוחות שלכם מוגן? בדיקת אבטחה למערכת שנבנתה בכלי AI

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

מאת , מייסד Agentical

פורסם ב- , עודכן ב-

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

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

שלושה אירועים מתועדים, ומה כל אחד מהם אומר לכם

  • מאי 2025, Lovable: במאגר החולשות הלאומי של ארה״ב נרשמה חולשה שמספרה CVE-2025-48757, ולפיה כללי גישה לא מספיקים אפשרו לקרוא ולכתוב בטבלאות של אפליקציות שנבנו ב-Lovable, בלי להתחבר. Lovable חולקת על הרישום, בנימוק שכל לקוח אחראי להגן על המידע של האפליקציה שלו[10]. אצלכם: בדיקה 2, מי יכול לקרוא איזה מידע.
  • יולי 2025, Base44: חוקרי Wiz מצאו דרך להירשם לאפליקציות פרטיות בלי הזמנה, ודיווחו עליה ב-9 ביולי. התיקון הותקן בתוך פחות מ-24 שעות, ו-Wix, הבעלים של Base44, הודיעה שלא מצאה עדות לניצול[11]. אצלכם: בדיקה 4, מי נכנס לאפליקציה וחשבונות שאתם לא מכירים.
  • פברואר עד אפריל 2026, Lovable: לפי Lovable, מ-3 בפברואר ועד 20 באפריל היו היסטוריית הצ׳אט וקוד המקור של פרויקטים ציבוריים נגישים לכל משתמש Lovable שהיה לו הקישור. פרויקטים פרטיים ו-Lovable Cloud לא נפגעו[9]. אצלכם: בדיקה 3, מפתחות שנכתבו פעם בצ׳אט או בקוד.

הרשימה נשענת רק על מקורות ראשונים: היצרן, החוקרים שגילו את החולשה ומאגר החולשות הרשמי. דיווחים של צד שלישי על היקף הנזק לא נכללו, כי לא יכולנו לאמת אותם.

ולמה זה חשוב גם לעסק עצמו: תקנות הגנת הפרטיות (אבטחת מידע) חלות על כל גוף בישראל, פרטי או ציבורי, שמנהל או מעבד מידע אישי דיגיטלי על אנשים[29]. לפי המדריך של הרשות להגנת הפרטיות לעצמאים ולעסקים קטנים, גם מספר תעודת זהות הוא מידע שצריך להגן עליו[30]. הרשימה כאן היא בדיקה מעשית, לא ייעוץ משפטי. מה החוק דורש מהעסק שלכם בודקים עם מי שמתמחה בזה.

לפני שמתחילים: חמש דקות הכנה

  1. רשמו איזה מידע אישי יש במערכת

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

  2. פתחו שני משתמשי בדיקה

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

  3. פתחו חלון גלישה פרטית

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

טוב לדעת

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

בדיקה 1: הריצו את סריקת האבטחה של הכלי

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

איפה נמצאת סריקת האבטחה בכל כלי, ומה כלול בה
כליאיפה מפעילים, ומה כלול
Lovableבסרגל של הפרויקט: More ואז Security[2]. סריקה מהירה רצה לבד בכל פרסום ובודקת את כללי הגישה ואת הרכיבים החיצוניים. סריקה עמוקה עוברת על כל הקוד, ומפעילים אותה ידנית. שתיהן לא צורכות קרדיטים[2]
Base44בעורך: Dashboard, אחר כך Security, ושם Run Security Scan[13]. זמינה בכל התוכניות, כולל החינמית: הרשאות נתונים, מפתחות חשופים, פונקציות שרת שלא בודקות מי פונה אליהן ורכיבים חיצוניים. בדיקת הקוד עצמו דורשת תוכנית Builder ומעלה[13]
Replitבחלונית Tools: Security Center[17]. רמה 1 חינמית ובודקת רק את הרכיבים החיצוניים. סקירת הקוד, ברמה 2, דורשת תוכנית בתשלום[17]
Boltבתפריט Publish: Run security audit[19]. בדיקה של כל הפרויקט, בתוכניות בתשלום, בלי לצרוך טוקנים. בדיקה של מסד הנתונים בלבד זמינה בכל התוכניות, דרך סמל מסד הנתונים ואז Security[20]
Emergentאין מסך סריקה נפרד. לפי התיעוד, סוכן סקירה של Emergent מריץ סריקות אבטחה כחלק מהעבודה של ה-AI[23], ויש רשימת בדיקות לפני פרסום[24]. בתיעוד לא מצאנו דוח ממצאים שבעל המערכת מריץ וקורא בעצמו. את בדיקות 2 עד 4 עושים ידנית, ובמערכת עם מידע רגיש שווה לבקש סקירה מקצועית

איך נראה תקין

הסריקה האחרונה רצה אחרי השינוי האחרון במערכת, ואין ממצא בדרגה החמורה ביותר, Critical, שעדיין פתוח. גם תוצאה נקייה היא לא תעודת ביטוח: Lovable כותבת שגם כשהסריקה לא מצאה כלום, היא לא יכולה לתפוס כל סיכון אפשרי[2], ו-Replit כותבת שאף סריקה לא מבטיחה שהאפליקציה מאובטחת[17].

שימו לב

תיקון אוטומטי משנה את המערכת. ב-Base44, למשל, תיקון שמחייב משתמש מחובר בפונקציית שרת יכול לשבור עמוד שמוצג לאורחים, או חיבור של שירות חיצוני שפונה לאפליקציה[13]. אחרי כל תיקון, עברו בעצמכם על התהליכים החשובים (הרשמה, הזמנה, תשלום), והריצו את הסריקה שוב.

בדיקה 2: מי יכול לקרוא איזה מידע

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

  1. פתחו את רשימת הכללים

    ב-Lovable: More, אחר כך Cloud, אחר כך Database, ושם RLS policies[1]. ב-Base44: Dashboard, בוחרים טבלה תחת Data ולוחצים Permissions. כלל בשם All Users אומר שכל אחד יכול לבצע את הפעולה, גם בלי להתחבר[14]. ב-Bolt: סמל מסד הנתונים ואז Security, ושם מופיעה למשל האזהרה RLS Policy Always True, כלומר כלל שמאשר תמיד[20]. ב-Replit וב-Emergent הכללים כתובים בקוד, ואותם בודקת הסריקה, או מי שקורא קוד.

  2. השוו לרשימה שהכנתם

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

  3. בדקו כאורח

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

  4. בדקו עם שני משתמשי הבדיקה

    התחברו כמשתמש א׳ וצרו רשומה: הזמנה, פנייה או פרופיל. בחלון אחר התחברו כמשתמש ב׳ וחפשו אותה. אם ב׳ רואה את הרשומה של א׳, הכלל פתוח מדי. ב-Base44 יש לזה כלי מובנה, Test Permissions in preview, שפותח את האפליקציה כפי שמשתמש מסוים רואה אותה. שינויים שתעשו בזמן הבדיקה נשמרים בנתונים של אותו משתמש, ולכן כדאי לבדוק עם משתמשי דוגמה[14].

איך נראה תקין

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

בדיקה 3: מפתחות שנשארו בצד הלא נכון

מפתח, או בשמו באנגלית API key, הוא הסיסמה שבה המערכת שלכם נכנסת לשירות אחר: סליקה, שליחת SMS, שירות AI. כל מה שכתוב בקוד שרץ בדפדפן גלוי לכל מי שנכנס לאפליקציה, ולכן Lovable כותבת שמפתח שהגיע לקוד כזה צריך להיחשב חשוף[3]. המקום של מפתחות הוא אזור הסודות של הכלי, שנקרא בממשק Secrets, שממנו רק צד השרת קורא אותם[12].

  1. בדקו מה הסריקה מצאה

    הסריקות של Base44[13], של Lovable[1] ושל Bolt[19] מחפשות מפתחות שנשארו בקוד או במקום שמבקרים יכולים להגיע אליו. ממצא כזה מטפלים בו לפני כל דבר אחר.

  2. בדקו שכל מפתח יושב באזור הסודות

    בכל כלי יש אזור נפרד לסודות, ובדרך כלל הוא נקרא Secrets: ב-Lovable[7] וב-Replit[18] זה מסך בשם הזה, ב-Bolt הוא בהגדרות של מסד הנתונים[21], וב-Emergent תחת Preview ואז Manage[25]. השוו לרשימת השירותים שהמערכת עובדת איתם: שירות שעובד, בלי שהמפתח שלו מופיע באזור הסודות, הוא סימן שהמפתח כתוב במקום אחר.

  3. שאלו אם מפתח הודבק פעם בצ׳אט או בקוד

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

מפתח שנחשף מחליפים, לא מעבירים

להעביר מפתח חשוף לאזור הסודות לא מספיק, כי מי שראה אותו עדיין מחזיק בו. נכנסים לשירות שהנפיק אותו, יוצרים מפתח חדש, שומרים את החדש בסודות ומבטלים את הישן. ב-Lovable אי אפשר לקרוא שוב סוד אחרי שנשמר, ואם מפתח אבד, מייצרים חדש בשירות שהנפיק אותו[7].

עוד שתי נקודות, לפי כלי. ב-Emergent, ערך של סוד מוסתר אחרי השמירה, אבל לפי התיעוד, כל מי שיש לו גישה לאפליקציה המפורסמת בממשק של Emergent יכול לחשוף ולהעתיק אותו[25]. ב-Base44, הסריקה מסמנת יכולות שצורכות קרדיטים, כמו AI, יצירת תמונות או מיילים, כשאפשר להפעיל אותן ישירות מבחוץ, כי מי שימצא אותן יכול לבזבז לכם את הקרדיטים[13].

איך נראה תקין

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

בדיקה 4: מי נכנס לפרויקט, ומי מנהל באפליקציה

יש שתי דלתות נפרדות, ובודקים את שתיהן. הראשונה היא הכלי עצמו: מי יכול לפתוח את הפרויקט, לראות את הקוד ואת הצ׳אט, ולשנות. השנייה היא האפליקציה: מי יכול להיכנס אליה, ומי מנהל בה. ב-Lovable אלה שתי הגדרות עצמאיות: פרסום האפליקציה לא משנה מי רואה את הפרויקט, ולהפך[4]. ב-Base44, תפקיד Admin באפליקציה לא נותן גישה לעורך או ללוח הבקרה, ורק שותפי העבודה והבעלים נכנסים לשם[15].

  1. מי רואה את הפרויקט בכלי

    ב-Lovable: כפתור Share בפרויקט מציג את כל מי שיש לו גישה, עם התפקיד של כל אחד, ואת אנשי סביבת העבודה רואים ב-Workspace settings ואז People[5]. ב-Emergent: Settings ואז Members[26]. ברשימה צריכים להופיע רק מי שעובד על המערכת היום. פרילנסר שסיים, עובד שעזב, חשבון ניסיון: מסירים.

  2. מה כל אחד מהם יכול לעשות

    עורך בפרויקט יכול יותר ממה שנדמה. ב-Lovable, למשל, כל מי שיש לו הרשאת עריכה יכול לשחזר את מסד הנתונים לגיבוי קודם, ומה שנוצר או השתנה אחרי הגיבוי אובד[6]. ב-Replit, הסודות משותפים עם מי שעובד איתכם על הפרויקט[18], ולכן אחרי שמסירים מישהו, מחליפים את המפתחות שהוא ראה.

  3. מי יכול לפתוח את האפליקציה

    ב-Base44: Dashboard, Overview ואז App Visibility. Public פירושו כל אחד באינטרנט, בלי התחברות. Private פירושו רק מי שהוזמן, והוא זמין רק בתוכניות בתשלום[15]. מערכת פנימית לצוות לא צריכה להיות פתוחה לכולם.

  4. מי מנהל באפליקציה

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

  5. מי מחזיק בחשבון הראשי

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

איך נראה תקין

ברשימות מופיעים רק אנשים שעובדים על המערכת היום, החשבון הראשי שייך לעסק, ומערכת שנועדה לצוות פתוחה רק לצוות. שווה לבדוק גם הגנה מפני סיסמאות שכבר דלפו ברשת: ב-Bolt היא פועלת כברירת מחדל[20], וב-Lovable הסריקה המהירה מסמנת אותה כשהיא כבויה[1].

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

אבטחה היא גם היכולת לחזור אחורה: אחרי מחיקה בטעות, תיקון שהשתבש, או משתמש שעשה נזק. שני דברים מפתיעים כמעט כל בעל מערכת. הראשון: חזרה לגרסה קודמת בכלי מחזירה בדרך כלל את הקוד, לא את הנתונים. כך ב-Bolt[22], וכך ב-Emergent, שבו חזרה לגרסה קודמת של האפליקציה המפורסמת משאירה את מסד הנתונים כמו שהוא[27]. השני: גיבוי שקיים רק בתוך הכלי תלוי בכלי. ב-Lovable יש גיבוי יומי של מסד הנתונים, לכ-14 יום אחורה, אבל הוא שמור ב-Lovable ולא כולל את הקבצים שהועלו[6].

  1. יש לכם עותק מחוץ לכלי?

    עותק של מסד הנתונים ושל הקבצים, מהחודש האחרון, שמור במקום שבשליטת העסק. ב-Lovable יש ייצוא מלא של מסד הנתונים, וכך מוציאים אותו, צעד אחרי צעד. גם ל-Base44 יש מדריך משלו: מה יוצא ממנה ואיך. ול-Emergent: איך מגיעים לעותק של הנתונים החיים, ולא רק של נתוני הבדיקה. ב-Bolt, שחזור גרסה לא מחזיר נתונים[22], וכך בוחרים איך להוציא את מסד הנתונים.

  2. מישהו בדק שאפשר לשחזר ממנו?

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

איך נראה תקין

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

בדיקה 6: תשלומים ומידע רגיש

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

  1. מצאו את השדות הרגישים

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

  2. שאלו על כל שדה: למה הוא כאן?

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

  3. בדקו איך עוברים התשלומים

    מספר כרטיס אשראי לא צריך להישמר בטבלה שלכם: התשלום עובר דרך חברת הסליקה, בעמוד או ברכיב שלה. הסריקות של Lovable[1] ושל Bolt[19] מחפשות גם דרכים שבהן לקוח יכול לשנות מחיר או לקבל שירות בתשלום בלי לשלם.

איך נראה תקין

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

בדיקה 7: רכיבים חיצוניים ועדכונים

כל אפליקציה בנויה גם מעשרות רכיבי קוד מוכנים שאנשים אחרים כתבו. כשמתגלה חולשה ברכיב כזה, היא עוברת לכל מי שמשתמש בו. ברשימת עשרת הסיכונים החמורים לאפליקציות ווב של OWASP, בגרסת 2025, כשלים בשרשרת האספקה של התוכנה נמצאים במקום השלישי[28].

כאן הכלים עושים את רוב העבודה. ב-Lovable, בדיקת הרכיבים רצה לבד בכל פעם שהם משתנים[1]. ב-Replit, חומת הגנה שפועלת כברירת מחדל חוסמת רכיבים זדוניים כבר בהתקנה, וסריקה אוטומטית מזהה חולשות חדשות ברכיבים שכבר מותקנים. אפשר גם לחסום שם פרסום של גרסה עם חולשה חמורה, ב-Publish ואז Advanced[16]. ב-Base44 בדיקת הרכיבים היא חלק מהסריקה, וכשאין עדיין גרסה מתוקנת, היא מציעה להחליף את הרכיב בעזרת ה-AI[13].

איך נראה תקין

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

מצאתם משהו פתוח? מה עושים, לפי הסדר

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

  1. תעדו לפני שמתקנים

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

  2. סגרו את הפרצה

    הגבילו את הכלל הפתוח, הפכו את האפליקציה לפרטית, הסירו גישה מיותרת או החליפו את המפתח שנחשף. ב-Base44 כל תיקון של הסריקה נשמר בצ׳אט עם נקודת שחזור, ואם הוא שבר משהו, אפשר לחזור ממנה[13].

  3. בדקו אם מישהו השתמש בפרצה

    חפשו משתמשים שנרשמו ואתם לא מכירים, פעולות חריגות ושינויים בנתונים שאף אחד בצוות לא עשה. אחרי החולשה ב-Base44, למשל, Wiz המליצה לעבור על נתוני הכניסות וההרשמות לאפליקציה ולחפש פעילות חריגה בתקופה הרלוונטית[11].

  4. רשמו את האירוע

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

  5. בררו אם צריך לדווח

    לרשות להגנת הפרטיות יש שירות מקוון לדיווח מיידי על אירוע אבטחה חמור במאגר מידע[31]. אם מידע אישי נחשף, התייעצו עם מי שמתמחה בדיני פרטיות: האם אתם חייבים לדווח, למי ומתי.

  6. אם הבעיה בכלי עצמו, דווחו ליצרן

    ל-Base44 יש תוכנית לדיווח על חולשות[12], ו-Lovable מקבלת דיווחים דרך תוכנית הדיווח האחראי שלה[9].

טוב לדעת

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

כל הרשימה בעמוד אחד

שבע הבדיקות, ואיך נראה תקין בכל אחת
בדיקהאיך נראה תקין
1. סריקת האבטחה של הכלירצה אחרי השינוי האחרון, ואין ממצא חמור פתוח
2. מי יכול לקרוא איזה מידעאורח לא רואה מידע אישי, ומשתמש רואה רק את שלו
3. מפתחותכולם באזור הסודות, וכל מפתח שנחשף הוחלף
4. מי נכנס לפרויקט ולאפליקציהרק מי שעובד על המערכת היום, והחשבון הראשי שייך לעסק
5. גיבויעותק עדכני מחוץ לכלי, ששוחזר בהצלחה פעם אחת
6. תשלומים ומידע רגישאין מספרי כרטיס, וכל שדה רגיש נחוץ וסגור
7. רכיבים ועדכוניםאין רכיב עם חולשה חמורה שלא עודכן

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

מה הרשימה הזו לא מחליפה

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

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

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

איך הכנו את המדריך

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

נבדק מול התיעוד הרשמי ב-.

מקורות

  1. Security overview Lovable · נבדק ב-
  2. Project security view Lovable · נבדק ב-
  3. Security best practices for Lovable apps Lovable · נבדק ב-
  4. Control project access Lovable · נבדק ב-
  5. Collaboration Lovable · נבדק ב-
  6. Database Lovable · נבדק ב-
  7. Secrets Lovable · נבדק ב-
  8. Terms of Service (version of August 28, 2026), "No Sensitive Data" Lovable · נבדק ב-
  9. Our response to the April 2026 incident Lovable · נבדק ב-
  10. CVE-2025-48757 Detail (marked "disputed") National Vulnerability Database (NIST) · נבדק ב-
  11. Critical Vulnerability in AI Vibe Coding platform Base44 Wiz Research · נבדק ב-
  12. Base44 security: An overview Base44 · נבדק ב-
  13. Running a security scan Base44 · נבדק ב-
  14. Managing data permissions Base44 · נבדק ב-
  15. Choosing who can access your app Base44 · נבדק ב-
  16. Security Replit · נבדק ב-
  17. Security scan levels Replit · נבדק ב-
  18. Secrets Replit · נבדק ב-
  19. Check your project's security Bolt · נבדק ב-
  20. Database: Security settings Bolt · נבדק ב-
  21. Database: Secrets settings Bolt · נבדק ב-
  22. Backups, restore, and version history Bolt · נבדק ב-
  23. How the agent runs (workflow & stop reasons) Emergent · נבדק ב-
  24. Pre-publish health check for web apps Emergent · נבדק ב-
  25. Secrets & env variables Emergent · נבדק ב-
  26. Team roles, permissions & collaboration Emergent · נבדק ב-
  27. Publishing types Emergent · נבדק ב-
  28. OWASP Top 10:2025 OWASP Foundation · נבדק ב-
  29. תקנות הגנת הפרטיות (אבטחת מידע) הרשות להגנת הפרטיות · נבדק ב-
  30. מדריך תקנות הגנת הפרטיות (אבטחת מידע) לעצמאים ולעסקים קטנים הרשות להגנת הפרטיות · נבדק ב-
  31. הרשות להגנת הפרטיות: שירותים, ובהם דיווח על אירוע אבטחה חמור במאגר מידע הרשות להגנת הפרטיות · נבדק ב-

שאלות על אבטחה במערכת שנבנתה בכלי AI

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

חלקית. סריקה נקייה אומרת שהבעיות הנפוצות לא נמצאו, לא שאין בעיות. Lovable כותבת שגם כשהסריקה לא מצאה כלום, היא לא יכולה לתפוס כל סיכון אפשרי[2], ו-Replit כותבת שאף סריקה לא מבטיחה שהאפליקציה מאובטחת[17]. הוסיפו את בדיקת האורח ואת בדיקת שני המשתמשים, שבודקות איך האפליקציה מתנהגת בפועל.

מותר לשמור מספרי תעודת זהות באפליקציה שנבנתה ב-Lovable?

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

הדבקתי פעם מפתח בצ׳אט של הכלי. מה עושים עכשיו?

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

אם האפליקציה שלי ב-Lovable מפורסמת, כל אחד יכול לראות גם את הקוד שלה?

לא. ב-Lovable, מי שנכנס לאפליקציה המפורסמת ומי שרואה את הפרויקט בעורך נקבעים בשתי הגדרות נפרדות, ופרסום לא נותן לאף אחד גישה לקוד, לצ׳אט או לשינויים שלא פורסמו. מאז 22 באפריל 2026 כבר אי אפשר ליצור ב-Lovable פרויקטים ציבוריים[4].

אני לא טכני. אפשר לעשות את הבדיקות האלה לבד?

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

רוצים לדעת איך המעבר ייראה אצלכם?

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

בואו נדבר וואטסאפ