מי יכול לראות את הנתונים באפליקציה שבנית ב-AI — ואיך בודקים את זה ב-10 דקות

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

עכשיו שאלה אחת, והיא לא תיאורטית: מה בדיוק מונע מאדם אחר לראות את הנתונים האלה?

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

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

קודם כול — איך האפליקציה שלך בנויה, בשתי פסקאות#

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

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

המקרה המתועד — ומה שהופך אותו למעניין#

ב-30 במאי 2025 פורסמה רשומת CVE-2025-48757, רשומת ליקוי רשמית שמנוהלת על ידי MITRE. היא נוגעת ל-Lovable, והיא מסווגת בחומרה 9.3 מתוך 10 — “קריטי” (‎CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N), תחת הסיווג CWE-863 — “הרשאה שגויה”.

זה התיאור הרשמי, כפי שהוא כתוב ברשומה עצמה (התרגום שלי):

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

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

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

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

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

מה לא כתוב ברשומה, ולכן לא תמצא כאן#

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

עדכון, 1.10.2026: באפריל 2026 Lovable עצמם פרסמו בבלוג שלהם אירוע נוסף, מסוג אחר. בין 3 בפברואר ל-20 באפריל 2026, היסטוריית הצ׳אט וקוד המקור של פרויקטים ציבוריים היו נגישים לכל משתמש מחובר שהיה לו קישור לפרויקט. לפי Lovable, פרויקטים פרטיים ו-Cloud לא נפגעו, והתקלה תוקנה. זה לא נוגע לנתונים של המשתמשים באפליקציה שלך, אבל זו סיבה טובה לבדוק שהפרויקט שלך מוגדר כפרטי.

מה שכן נכון לכל הכלים, בלי יוצא מן הכלל: Vibe CodingⓘVibe Coding Vibe Codingלתאר ל-AI מה אתה רוצה ולקבל תוכנה עובדת, בלי לקרוא את הקוד שיצא — מילת השנה של מילון קולינס ל-2025.להסבר המלא ← מייצר לך אפליקציה עובדת, לא אפליקציה מאובטחת. אלה שני דברים שונים, והשני הוא שלב שאתה צריך לבקש במפורש.

הבדיקה: עשר דקות, בלי לדעת שורת קוד#

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

בדיקה 1: חלון גלישה בסתר#

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

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

בדיקה 2: שני משתמשים — הבדיקה שהכי חשוב לעשות#

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

1. הירשם לאפליקציה כמשתמש א׳ והכנס נתון מזהה — למשל לקוח בשם “בדיקה אלף”.
2. פתח דפדפן אחר, או חלון בסתר, והירשם כמשתמש ב׳ עם מייל אחר לגמרי.
3. הסתכל על המסך של משתמש ב׳.

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

בדיקה 3: תשאל את הכלי, בניסוח שלא מאפשר לו להתחמק#

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

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

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

בדיקה 4: “מופעל” זה לא “מגן”#

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

אפשר להפעיל הגנה ברמת השורה על טבלה, ובאותה נשימה להגדיר לה מדיניות שאומרת “כולם רשאים לקרוא הכול”. במצב הזה תקבל ✅ ירוק בכל מסך בקרה — וההגנה שווה אפס. לכן בדיקה 3 מבקשת לראות את המדיניות עצמה, ולכן בדיקה 2 היא הקובעת: היא בודקת את התוצאה בפועל, לא את ההצהרה.

מה מתקנים היום#

ארבעה דברים, לפי הסדר.

1. בקש מהכלי, במפורש, להפעיל הגנה ברמת השורה על כל טבלה שיש בה נתונים של משתמשים — ולכתוב מדיניות שמגבילה כל משתמש לשורות שלו בלבד. זו בקשה שהכלים יודעים לבצע; הם פשוט לא תמיד עושים אותה מיוזמתם.
2. חזור על בדיקה 2 אחרי התיקון. לא “הכלי אמר שתיקן” — תבדוק בעצמך עם שני משתמשים. זה לוקח שתי דקות.
3. הוצא מפתחות של שירותים חיצוניים מהקוד שרץ בדפדפן. אם חיברת שירות תשלומים, שליחת מיילים או APIⓘAPI Application Programming Interfaceהדלת שדרכה תוכנה אחת מדברת עם אחרת — ובכלים רבים היא נעולה מאחורי מסלול יקר יותר.להסבר המלא ← כלשהו, המפתח שלו לא אמור לשבת במקום שכל גולש יכול לקרוא. תשאל את הכלי איפה הוא שמר כל מפתח, ובקש להעביר אותם לאחסון סודות.
4. אל תבדוק על הנתונים האמיתיים. תחזיק פרויקט נפרד לניסויים. סביבת בדיקותⓘסביבת בדיקות Stagingעותק של האתר שרק אתה רואה, לבדוק שינויים לפני שהם עולים ללקוחות — ובכלים רבים, תכונה של המסלול היקר בלבד.להסבר המלא ← היא לא מותרות של חברות גדולות — היא ההבדל בין למחוק טבלת בדיקה לבין למחוק את הלקוחות שלך.

מה זה לא אומר#

זה לא אומר שאסור לבנות אפליקציה עם AI. הבעיה כאן היא לא שה-AI כותב קוד גרוע — הבעיה היא ששלב שהיה פעם ברור ומובנה בתהליך פיתוח קיבל בפריסהⓘפריסה Deployהרגע שבו מה שבנית הופך לזמין לאנשים אחרים — ובכלים המודרניים, כפתור אחד שמסתיר את כל מה שפעם היה שבוע.להסבר המלא ← המהירה הזו מעמד של “אופציה שצריך לבקש”.

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

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

אם אתה עוד בשלב שבו אתה בוחר כלי, Base44 מול Lovable ו-Lovable מול Bolt מכסים את ההבדלים בין הכלים עצמם, ו-מה זה No-Code מסביר איפה הם נשברים בכלל. ואם כבר חיברת דומיין ואתה לקראת לקוחות אמיתיים — חיבור דומיין ‎.co.il ו-איך גובים תשלום מישראל הם שני השלבים שבאים מיד אחרי זה.

כלים משלימים ששווה להכיר#

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

שאלות נפוצות#

מה זה בעצם RLS, במשפט אחד?

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

אם יש לי מסך התחברות, זה לא מספיק?

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

האם הבעיה הזו קיימת רק ב-Lovable?

לא. בחרתי להתמקד בה כי זו המקרה היחיד שמצאתי שיש לו רשומה רשמית שיכולתי לאמת — רשומת CVE-2025-48757 שמנוהלת על ידי MITRE. המבנה עצמו — דפדפן שפונה ישירות למסד נתונים עם מפתח ציבורי — משותף לכלים רבים בקטגוריה, ולכן ארבע הבדיקות במאמר לא תלויות בכלי מסוים.

הליקוי הזה עדיין פתוח?

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

מה זה אומר שהרשומה “שנויה במחלוקת”?

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

בניתי משהו קטן לשימוש פנימי — גם עליי זה חל?

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

סיכום: מה לעשות עכשיו#

1. בדיקה 2, עכשיו — שני משתמשים, שני דפדפנים. זו הבדיקה שמכריעה.
2. אם היא נכשלה — אל תשלח עוד קישורים, ובקש מהכלי להפעיל הגנה ברמת השורה על כל טבלה עם מדיניות שמגבילה כל משתמש לשורות שלו.
3. בדוק שוב אחרי התיקון, בעצמך. “הכלי אמר שתיקן” הוא לא אימות.
4. בקש רשימה מלאה של הטבלאות והמדיניות שלהן (הניסוח נמצא בבדיקה 3) ושמור אותה. זה המסמך שתרצה ביד כשלקוח ישאל אותך על אבטחה.
5. הפרד סביבת בדיקות מהאפליקציה החיה לפני הלקוח הבא, לא אחריו.