בדיקת אבטחה למערכת שנבנתה עם AI: מה בודקים לפני שפותחים אותה ללקוחות
מערכת שנבנתה עם AI יכולה לעבור כל הדגמה ועדיין לתת למשתמש אחד לפתוח את הנתונים של משתמש אחר. על המסך זה לא נראה. בפועל זה אומר שפרטים של לקוחות נחשפים, שאפשר לבצע פעולות בשם משתמש אחר, או שמפתח שפותח את כל מסד הנתונים יושב בקוד הדף.
בדיקת אבטחה עונה על שאלה אחת: אפשר לפתוח את המערכת למשתמשים אמיתיים, ואם לא, מה סוגרים קודם. כך בודקים את זה במערכות שנבנו ב-Lovable, ב-Base44, ב-Claude או ב-ChatGPT, על בסיס OWASP ASVS 5.0.0, התקן המקצועי לאימות אבטחה של יישומים. אני עובד עם הכלים האלה ומשלים מערכות שנבנו בהם, ומערכת שאני בונה עולה לאוויר רק כשהיא מאובטחת במידה שמתאימה לפעילות העסקית שלה.
האם אפליקציה שנבנתה ב-Lovable או ב-Base44 בטוחה?
זה תלוי בשכבה, והאחריות מתחלקת. את התשתית ואת מנגנון ההתחברות מספקת הפלטפורמה, וכשנמצאת בהם פרצה, היא זו שמתקנת. את ההרשאות לנתונים, את המפתחות ואת הכללים העסקיים של האפליקציה הספציפית כתב ה-AI לפי מה שביקשו ממנו, ומי שבונה ומפעיל אותה צריך לוודא שהם נכונים. גם Lovable כותבת בתיעוד שלה שהמשתמש אחראי לכך שהאפליקציה עומדת בדרישות האבטחה שמתאימות לה.
ועל הקוד עצמו אי אפשר לסמוך בלי בדיקה. במבחנים של Veracode, שפורסמו ביולי 2026, קוד שמודלים כתבו בלי הנחיה מיוחדת לאבטחה עבר את בדיקות האבטחה בממוצע ב-56% מהמשימות, כמעט בלי שינוי מהשנה הקודמת.
ויש מקרים פומביים. במאי 2025 פורסמה חולשה רשמית (CVE-2025-48757) באפליקציות שנבנו ב-Lovable עד אפריל 2025, שבהן מדיניות ההרשאות במסד הנתונים לא הגבילה מספיק, ומי שלא התחבר יכול היה לקרוא ולשנות טבלאות. החברה חולקת על הסיווג. ביולי 2025 פרסמה Wiz שבעזרת מזהה האפליקציה, שאינו סוד, ושתי נקודות גישה לא מתועדות, אפשר היה ליצור חשבון מאומת באפליקציה פרטית ב-Base44. התיקון יצא בתוך יממה, ולא נמצאה עדות לניצול. ובאפריל 2026 פרסמה Lovable שמפברואר, קוד המקור והשיחות של פרויקטים ציבוריים היו נגישים למשתמשים אחרים בפלטפורמה שהיה להם קישור. פרויקטים פרטיים לא נפגעו, אבל מפתח שנכתב בקוד של פרויקט ציבורי עלול היה להיחשף.
כשבדקתי אב-טיפוס שנבנה בשיחה עם כלי AI והגיע אליי לבדיקה, מצאתי 9 דברים שעבדו בהדגמה ולא היו מוכנים ללקוחות, ורובם היו בשכבות האלה בדיוק.
מה בודקים: שבע שכבות
| שכבה | מה נשבר בדרך כלל | איך בודקים |
|---|---|---|
| הרשאות לנתונים | משתמש מגיע לרשומה של משתמש אחר, או טבלה פתוחה בלי מדיניות הרשאות | כל תפקיד בנפרד, אותה כתובת, ובדיקת ההרשאות במסד הנתונים |
| מפתחות וסודות | מפתח עם הרשאות מלאות בקוד שהדפדפן מוריד | חיפוש בקוד הדף, בבקשות ובהגדרות |
| התחברות וסשנים | איפוס סיסמה, אסימונים שלא פגים, התנתקות שלא מנתקת | מעבר על כל זרימה מול מה שהשרת באמת בודק |
| כללים עסקיים ותשלום | מחיר, הרשאה או אישור תשלום שנקבעים בדפדפן | בקשה ישירה לשרת, בלי הממשק |
| קלט מבחוץ | הזרקת קוד, קבצים שעולים בלי בדיקה | קלט חריג, בלי לשנות נתונים אמיתיים |
| תלויות ושרשרת אספקה | ספריות ישנות או מיותרות, קוד שנטען משרת זר | סריקת תלויות וגרסאות |
| רכיבי AI במערכת | הוראות שמוזרקות דרך תוכן, סוכן עם הרשאות רחבות מדי | ניסיון להטות את המודל, ובדיקה מה הוא מבצע לבד |
הרשאות לנתונים ולפעולות. כאן נמצאות רוב הבעיות, ולכן אני בודק כל תפקיד בנפרד. במערכת הזמנות, למשל, לקוח רואה רק את ההזמנות שלו, נציג שירות רק את מה שנדרש לו, מנהל את הכול, ומי שלא מחובר לא רואה כלום. ואז מנסים לעקוף: משנים מזהה בכתובת, ושולחים בקשה ישירה לשרת בלי הממשק. במערכות שנשענות על Supabase, ובהן הרבה ממה שנבנה ב-Lovable, כל טבלה בסכמה שחשופה ל-API צריכה מדיניות RLS, כלל שקובע לכל שורה מי רשאי לקרוא ולשנות אותה, ולצידה הרשאות מתאימות ברמת הטבלה. לפי התיעוד של Supabase, טבלה כזו בלי RLS פתוחה לקריאה ולכתיבה לכל תפקיד שיש לו הרשאה עליה.
רכיבי AI במערכת. ברשימת הסיכונים של OWASP ליישומי מודלי שפה, במהדורת 2026, הזרקת הוראות (Prompt Injection) נשארה במקום הראשון: טקסט שמגיע מבחוץ, במסמך או במייל, וגורם למודל לבצע הוראות שלא נועדו לו. סמכות מופרזת (Excessive Agency) עלתה מהמקום השישי לשלישי. לכן כשיש במערכת צ’אט או סוכן, בודקים באילו הרשאות הוא פועל, של המשתמש או של המערכת כולה, אילו פעולות הוא מבצע בלי אישור של אדם, כמו שליחה, מחיקה או תשלום, והאם הפעולות שלו נרשמות.
מה סריקה אוטומטית מוצאת, ומה היא לא רואה
סריקה אוטומטית מוצאת דפוסים מוכרים בקוד ובהגדרות. היא לא יודעת מה המערכת אמורה לעשות, ולכן לא יכולה לקבוע שהיא עושה רק את זה. גם התקן עצמו קובע שכלים אוטומטיים לא מאמתים לבדם הרשאות ולוגיקה עסקית.
ב-Lovable יש שתי סריקות: מהירה בכל פרסום, ומעמיקה שמפעילים ידנית. ב-Claude Code יש פקודת security-review שמחפשת בקוד הזרקות ובעיות הרשאה. ואתרים שמציעים בדיקת אבטחה לאתר בודקים כתובת מבחוץ: תעודת SSL, כותרות אבטחה וחומת אש. אני משתמש בכלים כאלה כנקודת התחלה, ו-Lovable עצמה כותבת שהכלים שלה לא מחליפים בדיקת אבטחה יסודית. אף אחד מהם לא מכיר את הכללים שרק העסק יודע, כמו מי מורשה לראות את כל ההזמנות.
לפי איזה תקן בודקים
התקן OWASP ASVS הוא רשימת דרישות לאימות אבטחה של יישומי רשת, שמפרסמת OWASP, קהילה פתוחה בתחום. גרסה 5.0.0 פורסמה ב-30 במאי 2025, ויש בה כ-350 דרישות ב-17 פרקים. לכל דרישה יש מזהה, כך שאפשר לכתוב בדוח בדיוק מה נבדק ולבדוק אותה שוב אחרי התיקון. זה לא תו תקן: OWASP לא מסמיכה מערכות או בודקים, ולכן דוח רציני אומר במפורש איזו רמה נבדקה, אילו דרישות ובאיזו שיטה.
בתקן שלוש רמות. L1 היא הבסיס, L2 מיועדת ליישומים שמעבדים מידע רגיש, ו-L3 למערכות שפריצה אליהן מסכנת הרבה. את הרמה קובעים לפי מודל הסיכון, וברוב המערכות שיש בהן לקוחות, מידע אישי או תשלום זו L2. ולפי גרסה 5.0, בדיקה מבחוץ בלבד לא מספיקה גם ברמה הראשונה, ולכן בדיקה אמיתית צריכה גישה לקוד ולהגדרות.
איך נראית בדיקה כזו, שלב אחרי שלב
- הגדרת היקף. קובעים מה נבדק: סביבת הייצור או סביבת בדיקה, אילו תפקידים, אילו שירותים חיצוניים ותהליכי תשלום, ואיזו רמה של התקן. מה שלא נבדק נכתב בדוח, עם הסיבה.
- מודל איומים. מי המשתמשים, איזה מידע נשמר, איפה עובר כסף, ומי עלול לנסות לנצל את המערכת. נוח לעבור על התרחישים לפי STRIDE: התחזות, שינוי נתונים, הכחשת פעולות, חשיפת מידע, השבתה והעלאת הרשאות. לעסק קטן התוקף המציאותי הוא בדרך כלל משתמש סקרן, בוט שסורק את האינטרנט, או טעות של מישהו מבפנים.
- ביקורת עם סוכן AI, בקריאה בלבד. הסוכן ממפה את הרכיבים שבהיקף: הקוד, מסד הנתונים וההרשאות שלו, הפונקציות בצד השרת והתלויות. הוא מריץ סריקות ובדיקות חיות שלא משנות נתונים, לא שולחות הודעות ולא מבצעות תשלום.
- אימות ידני. כל התרעה של כלי היא רק חשד. כל ממצא משוחזר ומתועד עם ראיה: קובץ ושורה, או בקשה ותשובה.
- מחוץ לתקן. ASVS עוסק באבטחה של האפליקציה עצמה. בנפרד בודקים את מה שמסביב לה: אימות דו-שלבי בחשבונות הניהול, מי עוד מחזיק גישה, גיבוי שאפשר באמת לשחזר ממנו, ואיפה שמורים הסודות.
וכשמשלימים מערכת כזו לפני העלייה לאוויר, כמו שאני עושה בהשלמה של מערכות שנבנו עם AI, הבדיקה הזו היא חלק מהעבודה, והממצאים נסגרים לפי מה שהעסק צריך.
מה צריך להיות בדוח
דוח טוב נפתח בהמלצה, בגבולות מה שנבדק: אפשר לפתוח למשתמשים, אפשר לפתוח אחרי שפעולות מסוימות נעשות, או שצריך לעצור ולתקן קודם. אחריו באה מפת כיסוי, שבה כל דרישה רלוונטית מקבלת אחד מארבעה סטטוסים: עבר (PASS), נכשל (FAIL), לא אומת (NOT VERIFIED) או לא רלוונטי (N/A), עם ראיה או נימוק.
“עבר” ניתן רק אחרי בדיקה בפועל: מדיניות RLS, למשל, מקבלת אותו כשמשתמשים שונים ניסו לגשת למה שאסור להם ונחסמו. ודרישה שלא היה אפשר לבדוק מסומנת “לא אומת”, ולא נספרת כאילו עברה.
כל ממצא מגיע עם מיקום, ראיה, תרחיש ניצול, חומרה (מ-Critical עד Low) ודרך לוודא שהתיקון עבד. תוכנית התיקון מסודרת לפי דחיפות, מ-P0, מה שסוגרים לפני שממשיכים, ועד P3, הקשחה ושיפורים. ולצד הדוח הטכני כדאי שתהיה גרסה קצרה לבעל העסק, בלי מונחים.
ואחוז העמידה הוא המספר הכי קל לקרוא לא נכון. ברוב הפרקים של התקן יש דרישות תיעוד, למשל מסמך שמגדיר את כללי ההרשאה, שנדרש כבר ברמה הראשונה. כשאין מסמך כזה, הדרישה לא עומדת, גם אם ההגנה עצמה עובדת. ומנגד, מערכת יכולה לעבור 90% מהדרישות וליפול על הדרישה שמונעת ממשתמש לראות נתונים של אחר. לכן ההמלצה בראש הדוח חשובה יותר מהאחוז.
חמש בדיקות שאפשר לעשות לבד
את הבדיקות האלה עושים רק במערכת שבבעלותך, עם משתמשי בדיקה ונתוני בדיקה.
- שני משתמשים, כתובת אחת. נכנסים עם משתמש בדיקה אחד, מעתיקים כתובת של רשומה פרטית, ופותחים אותה עם משתמש בדיקה אחר. אם התוכן מופיע, זה הדבר הראשון לתקן.
- בלי התחברות. מתנתקים ופותחים ישירות כתובות של עמודים פנימיים. אם התוכן מגיע לדפדפן ורק מוסתר, אפשר לראות אותו בכלי המפתחים.
- מפתחות בקוד. בכלי המפתחים מחפשים בקובצי ה-JavaScript ובבקשות את המחרוזת sb_secret, ובפרויקטים ישנים גם את service_role. מפתח סודי יכול להסתתר גם בקובצי source map ובהיסטוריה של הקוד.
- הרשאות במסד הנתונים. ב-Supabase נכנסים ל-Security Advisor ובודקים שאין אזהרה בשם RLS Disabled in Public, שאומרת שיש טבלה פתוחה בלי מדיניות הרשאות.
- הסוכן במערכת. מבקשים ממנו לחשוף את ההוראות שלו או לבצע פעולה שהמשתמש לא מורשה לה, ובודקים מה הוא מבצע בלי אישור.
הבדיקות האלה יכולות לחשוף כמה כשלים נפוצים, והן לא מחליפות ביקורת.
ומה החוק בישראל אומר
מאז 14 באוגוסט 2025 חל תיקון 13 לחוק הגנת הפרטיות, שנתן לרשות להגנת הפרטיות סמכות להטיל עיצומים כספיים. ביולי 2026 הוטל הראשון מהם: 256,000 ₪ על קופת חולים, שתקלה במערכת הדיגיטלית שלה אפשרה למבוטחים, בתנאים מסוימים, לראות מידע רפואי של קרובי משפחה. העיצום הוטל על הדיווח: הקופה דיווחה לרשות כחודשיים אחרי שידעה, כשכבר סיימה לבדוק ולתקן, והרשות הבהירה שדיווח ראשוני צריך להגיע סמוך לגילוי. אני לא עורך דין, ומה שחל על עסק מסוים כדאי לבדוק עם מי שכן.
שאלות שחוזרות
מה ההבדל בין ביקורת אבטחה לבין מבדק חדירות?
מבדק חדירות, שנקרא גם מבדק חוסן, מדמה תוקף ומחפש דרך פנימה. ביקורת שמבוססת על ASVS בודקת את המערכת גם מבפנים, את הקוד, ההגדרות וההרשאות, מול רשימת דרישות. במערכות שנבנו עם AI רוב הבעיות יושבות בהרשאות ובקוד, ולכן מתחילים שם. מבדק חדירות יכול לבוא אחרי זה.
האם מבדק חדירות הוא חובה בחוק?
לא לכל אתר או מערכת. לפי תקנות הגנת הפרטיות (אבטחת מידע) מ-2017, מבדקי חדירות וסקר סיכונים נדרשים במאגר מידע שחלה עליו רמת אבטחה גבוהה, אחת ל-18 חודשים לפחות, וביקורת תקופתית נדרשת ברמה בינונית או גבוהה, אחת ל-24 חודשים לפחות. איזו רמה חלה על מאגר מסוים, זו שאלה לעורך דין.
המפתח של Supabase מופיע בקוד הדף. זו בעיה?
תלוי איזה. המפתח הציבורי (publishable, ובפרויקטים ישנים anon) נועד להיות גלוי, ומגיע רק למה שמדיניות ה-RLS מאפשרת, כך שהוא לבד לא מעיד על בעיה. המפתח הסודי (secret, או service_role הישן) עוקף את כל המדיניות, ואסור שיופיע בדפדפן או במאגר הקוד. אם הוא שם, מחליפים אותו לפני כל דבר אחר.
בטוח לתת לסוכן AI לבדוק את המערכת?
כן, כשעובדים נכון: עותק של הקוד וייצוא של מבנה מסד הנתונים, בלי הנתונים עצמם, הרשאות קריאה בלבד, ומשתמשי בדיקה לבדיקות החיות. בדיקה שמגיעה לנתונים אמיתיים נעצרת שם, וזה הממצא. וסיסמאות ומפתחות לא עוברים בוואטסאפ או במייל.
מתי צריך בדיקה כזו?
לפני שפותחים את המערכת למשתמשים אמיתיים, לפני שמחברים תשלום, אחרי שינוי גדול בהרשאות או במבנה הנתונים, וכשסוכן AI מקבל הרשאה לפעול בשם משתמשים. העומק תלוי במה שהמערכת מחזיקה: במערכת קטנה עם מעט מידע רגיש, לפעמים הבדיקות העצמיות שלמעלה, יחד עם מעבר מסודר על ההרשאות, מספיקות.