האם אפליקציות וייב קודינג בטוחות? 8 פרצות שכדאי לבדוק

האם אפליקציות שנבנו בווייב קודינג בטוחות?

לא כברירת מחדל: כל המחקרים הגדולים שמצוטטים כאן מצאו פרצות אבטחה חמורות בחלק גדול מהאפליקציות שבדקו ^[3][4][5]. האפליקציות בדרך כלל עובדות. הבעיה היא מה הן מאפשרות לזרים לעשות.

ביקורת מ-2026 אספה 9,041 אפליקציות קוד פתוח שנבנו עם Claude Code ו-Lovable ובחנה 200 מהן שהיו פתוחות לציבור. היא מצאה 1,186 חולשות, וב-182 מתוך 200 האפליקציות (91.0%) הייתה לפחות אחת ^[4]. מתוך החולשות האלה, 65.77% דורגו כקריטיות או גבוהות, ומהן 18.47% קריטיות ^[4].

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

ליסודות השיטה ראו את המדריך של Pouyam בשם Vibe Coding Explained: What It Is, How It Works and the Real Risks (וייב קודינג: מה זה והסיכונים האמיתיים). לפרויקט ראשון, Vibe Coding for Beginners: How to Start Safely in 2026 (וייב קודינג למתחילים) מציע תוכנית התחלה. הדף הזה יורד רמה אחת עמוק יותר: הפרצות הספציפיות ואיך לבדוק כל אחת.

מה מוצאים מחקרי אבטחה באפליקציות וייב קודינג?

ארבעה מקורות עצמאיים מצביעים על אותה נקודת תורפה: מידע שהאדם הלא נכון יכול לקרוא או לשנות ^[1][3][4][5].

• ביקורת של 200 אפליקציות פעילות (2026): בקרת גישה פגומה הייתה הקטגוריה הגדולה ביותר, עם 339 מתוך 1,186 חולשות (28.58%), ופגעה ב-64.00% מהאפליקציות. הזרקה פגעה ב-54.00% וכשלי אימות ב-51.50% ^[4].
• מחקר ACM CCS 2026: ב-8,641 מאגרי Lovable עם היסטוריה מלאה, 11.2% מכללי הקריאה היו פתוחים למבקרים לא מחוברים, ול-61.2% מהמאגרים היה לפחות כלל אחד כזה. בדיקת שחזור אישרה את החשיפה ב-353 מתוך 400 מאגרים במדגם ^[5].
• Escape (אוקטובר 2025): סריקה פסיבית של יותר מ-5,600 אפליקציות ציבוריות שנבנו בפלטפורמות כמו Lovable,‏ Base44 ו-Create.xyz מצאה יותר מ-2,000 חולשות, יותר מ-400 סודות חשופים ו-175 מקרים של מידע אישי, ובהם רשומות רפואיות, מספרי IBAN (מזהי חשבונות בנק), מספרי טלפון וכתובות דוא"ל ^[3].
• CVE-2025-48757 (2025): סריקה שהסתיימה ב-21 במרץ 2025 מצאה 303 נקודות קצה של מסדי נתונים ב-170 מתוך 1,645 פרויקטים של Lovable, כ-10.3%, עם כללי שורות לא מספקים ^[1].

Escape מדגישה שהסריקה נמנעה מכל פעולה הרסנית, ולכן המספרים הם רף תחתון; בדיקה עמוקה יותר הייתה מוצאת יותר ^[3]. אותה זהירות חלה על כל המספרים כאן: המחקרים סופרים את מה שאפשר היה לראות מבחוץ.

למה כלי בינה מלאכותית בונים אפליקציות לא בטוחות?

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

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

בדיקות רחבות של מודלי בינה מלאכותית מראות את אותו פער. דוח GenAI Code Security Report 2026 של Veracode מצא שבבדיקות שלה כ-44% ממשימות יצירת הקוד הכניסו חולשת אבטחה ^[11]. מבחן השוואתי ש-AWS מצטטת מצא שההגדרה הטובה מבין 12 הגדרות סוכן פתרה נכון 57% מהמשימות, אך רק 11.8% באופן נכון ובטוח גם יחד ^[10].

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

אילו 8 פרצות אבטחה כדאי לבדוק קודם?

התחילו בפרצות שהמחקרים מוצאים בתדירות הגבוהה ביותר, לפי גודל הנזק האפשרי ^[1][3][4][5].

1. כללי מסד נתונים פתוחים: טבלאות בלי אבטחה ברמת השורה, או עם כללים שמאפשרים לכל מבקר לקרוא את כל השורות. זה היה שורש CVE-2025-48757 וממצאי ACM ^[1][5].
2. בקרת גישה פגומה: משתמש מחובר פותח רשומה של משתמש אחר על ידי שינוי מזהה בכתובת או בבקשה. זו הייתה הקטגוריה הגדולה בביקורת 2026 ^[4].
3. מפתחות סודיים בדפדפן: מפתח secret או service_role של Supabase, מפתח תשלומים או מפתח של ספק בינה מלאכותית שהוכנס לקוד הממשק. Escape מצאה יותר מ-400 סודות חשופים ^[3][6].
4. בדיקות התחברות חסרות או חלשות: דפים פרטיים או נתיבי API שעונים בלי הפעלה פעילה. כשלי אימות פגעו ב-51.50% מהאפליקציות שנבדקו ^[4].
5. הזרקה: קלט משתמש שמגיע לשאילתות או ל-HTML בלי בדיקה, נמצא ב-54.00% מהאפליקציות שנבדקו ^[4].
6. טבלאות פתוחות לכתיבה: כללים שמאפשרים למבקרים להוסיף או לשנות נתונים, לא רק לקרוא. במקרה ה-CVE, בקשה בלי אסימון התחברות הוסיפה רשומה שסומנה "שולם" ודילגה על שלב התשלום ^[1].
7. תגובות שחושפות יותר מדי: ממשקי API שמחזירים רשומות משתמש מלאות, כתובות דוא"ל או אסימונים כשהדף צריך רק שם. Escape ספרה 175 מקרים של מידע אישי חשוף ^[3].
8. גישה מסוכנת של סוכנים: סוכן תכנות שמחזיק בהרשאות של סביבת הייצור יכול לגרום נזק אמיתי; ביולי 2025 סוכן מחק מסד נתונים חי בזמן הקפאת קוד ^[10].

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

איך בודקים אפליקציית וייב קודינג מול הפרצות האלה?

השתמשו באפליקציה כמו תוקף: כזר, כמשתמש שני, ותוך קריאת מה שהדפדפן מקבל ^[1][4][5]. אף שלב לא דורש כלים מיוחדים.

1. צרו שני חשבונות בדיקה. צרו רשומה בחשבון A, העתיקו את הכתובת או המזהה שלה, התחברו כחשבון B ונסו לפתוח, לערוך ולמחוק אותה. אם זה עובד, בקרת הגישה פגומה ^[4].
2. חזרו על כך בלי התחברות. פתחו את אותן כתובות בחלון פרטי בלי הפעלה. במקרה ה-CVE, הסרת כותרת ההתחברות הספיקה כדי לעקוף כל בדיקה ^[1].
3. עקבו אחרי לשונית הרשת. בכלי המפתחים של הדפדפן, בדקו כל בקשה שהדף שולח ומה חוזר. התגובות צריכות להכיל רק את מה שהמסך צריך, אף פעם לא כתובות דוא"ל או אסימונים של משתמשים אחרים ^[3].
4. חפשו מפתחות בקוד הדף. חפשו מחרוזות שמתחילות ב-sb_secret_, את התווית service_role או מפתחות של ספקים כמו תשלומים או בינה מלאכותית. מפתח publishable הוא דבר צפוי; מפתח secret הוא מצב חירום ^[6].
5. בדקו את הכללים של כל טבלה. בלוח הבקרה של מסד הנתונים ודאו שאבטחה ברמת השורה פעילה בכל טבלה, וקראו כל כלל במילים פשוטות: מי יכול לקרוא, מי יכול לכתוב ^[7].
6. נסו קלט חריג. הדביקו טקסט ארוך מאוד, מירכאות ותגי HTML בכל טופס, ובדקו אם האפליקציה קורסת או מציגה אותם כקוד ^[4].

בדקו רק אפליקציות שלכם או כאלה שקיבלתם רשות לבדוק. אל תחקרו אפליקציות של אחרים בלי רשות בכתב.

איך מתקנים כללי Supabase פתוחים ומפתחות שדלפו?

הפעילו אבטחה ברמת השורה בכל טבלה, כתבו כללים צרים, שמרו מפתחות סודיים בשרת והחליפו כל מפתח שדלף ^[6][7][8].

• הפעילו אבטחה ברמת השורה בכל מקום. המדריך של Supabase אומר להפעיל אותה בכל טבלה בסכמה חשופה ^[7]. אחרי ההפעלה המפתח הציבורי לא מגיע לשום דבר עד שמוסיפים כללים ^[7].
• הסירו הרשאות ברירת מחדל. בפרויקטים שעדיין מעניקים אותן כברירת מחדל, טבלה ציבורית חדשה מתחילה עם כל ההרשאות שכבר ניתנו לתפקידים לא מחוברים (anon) ומחוברים (authenticated), והוספת כללים לא מבטלת אותן ^[7]. בטלו אותן והחזירו לכל תפקיד רק את מה שהוא צריך ^[7].
• כתבו כללים לפי משתמש. כלל לטבלה פרטית צריך להתאים למזהה של המשתמש המחובר, ולא פשוט לאפשר לכל מי שהתחבר. הימנעו מכללים שתמיד מתקיימים בטבלאות רגישות ^[2].
• שמרו מפתחות סודיים בצד השרת. מפתח publishable של Supabase בטוח בדפדפן רק משום שכללי השורות מגבילים אותו; מפתחות secret ו-service_role עוקפים כל כלל וחייבים להישאר בקוד השרת או בהגדרות סביבה מאובטחות ^[6].
• החליפו מפתחות שדלפו. אם מפתח סודי הגיע אי פעם לדפדפן או למאגר קוד ציבורי, החליפו אותו והשביתו את המפתח שנחשף, כפי שמייעץ המדריך למפתחות של Supabase ^[6].

נכון ל-15 בנובמבר 2026, התיעוד של Supabase אומר שהיא מוציאה משימוש את מפתחות anon ו-service_role הישנים עד סוף 2026 לטובת מפתחות publishable ו-secret ^[8]. מפתחות ה-secret החדשים מחזירים שגיאה (HTTP 401) כשמשתמשים בהם בדפדפן, אך מפתח שדלף עדיין אפשר להפעיל מכלים אחרים ^[6][8]. מעבר עכשיו הוא הזדמנות טובה לבדוק כל מפתח שאפליקציה משתמשת בו.

האם סורקי האבטחה המובנים תופסים הכול?

לא: סורקי הפלטפורמות עוזרים, אבל כמה מחקרים מראים שהם מפספסים את הכללים החשובים ביותר ^[1][2][5].

ב-2025 גילו החוקרים שעומדים מאחורי CVE-2025-48757 שהסורק של Lovable בדק רק אם קיים כלל שורות, לא אם הוא נכון ^[1]. ההודעה שלהם מוסיפה שבדיקת הפרסום של Lovable מסמנת טבלאות בלי כללים, אבל לא מראה אם הכללים מחמירים מספיק ^[2]. כלל פתוח עובר בדיקה כזו.

מחקר ACM מראה זאת במספרים: שיעור צנוע של כללים פתוחים, 6.3% בשישה כלים, עדיין השאיר 56.9% מהמאגרים עם לפחות טבלה חשופה אחת, כי די בכלל פתוח אחד ^[5]. החוקרים פרסמו כלי בדיקה חינמי שמסמן כללים כאלה לפני שמירת הקוד ^[5].

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

האם בטוח להשתמש באפליקציות שאחרים בנו בווייב קודינג?

היזהרו מכל דבר שמבקש מידע אישי, רפואי או פרטי תשלום, כי משתמשים לא יכולים לראות איך אפליקציה מגינה עליו ^[3][4]. Escape מצאה רשומות רפואיות ומספרי IBAN (מזהי חשבונות בנק) בין הנתונים החשופים ^[3].

כמה הרגלים פשוטים מקטינים את הסיכון. השתמשו בסיסמה ייחודית לכל אפליקציה חדשה, כדי שדליפה באחת לא תפתח אחרות; המדריך של Pouyam בשם Password Managers Explained: How They Work and Whether They Are Safe (מנהלי סיסמאות: איך הם עובדים) מסביר איך. שתפו רק את המידע שהאפליקציה צריכה, והעדיפו דפי תשלום של ספקי תשלום מוכרים על פני טפסים בתוך האפליקציה.

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