כלי AI יכולים לקצר את הדרך מרעיון למוצר, אבל מסך התחברות יפה עדיין לא מוכיח שמישהו נעל את מסד הנתונים.
🔗 קישור למוצר: Supabase
האפליקציה עולה, הטופס שומר פרטים, ואפשר כבר לשלוח לינק ללקוחות. מבחינת מי שבנה אותה בעזרת AI, זה הרגע שבו הרעיון הפך לעסק. אלא שבין מוצר שעובד למוצר ששומר על המידע שלכם יש בדיקה שקל לפספס: מי עוד יכול לקרוא את מסד הנתונים? מחקר חדש של חברת האבטחה UpGuard איתר 16,326 מסדי נתונים ב־Supabase עם טבלאות נגישות לקריאה. ביותר ממחציתם נמצאו אינדיקציות למידע אישי. Supabase מספקת תשתית לפיתוח אפליקציות, ובה מסדי נתונים, ניהול משתמשים ואחסון; במקרה הזה, הבעיה מתמקדת באופן שבו לקוחות הגדירו את הגישה למידע שלהם. עבור המשתמש שהשאיר פרטים באתר, ההבדל בין טעות של המפתח לטעות של כלי הפיתוח לא משנה הרבה.
המספר הגדול דורש גם דיוק. החוקרים אספו כ־300 אלף דומיינים עם סימנים לשימוש ב־Supabase ובדקו גישה לטבלאות. כדי להעריך איזה מידע עשוי להיחשף, הם ניתחו את מבנה הטבלאות, ולא קראו כל רשומה בכל מסד. לכן אין כאן ספירה של אנשים שנפגעו, וגם לא הוכחה שכל הטבלאות הפתוחות מכילות מידע פרטי. עם זאת, בדיקות ממוקדות העלו מקרים מוחשיים: שירות חניית רכבים אמריקאי חשף מידע על יותר מ־100 אלף לקוחות, לרבות מספרי טלפון ובחלק מהמקרים לוחיות רישוי; בשירות לייעוץ הגירה לקנדה נמצאו גם 884 סיסמאות בטקסט גלוי. בתגובה לדיווח המקורי ב־TechCrunch, מסרה Supabase שפרויקטים מאובטחים כברירת מחדל ושהאבטחה היא אחריות משותפת עם הלקוחות.
כדי להבין את הפער, צריך להפריד בין זיהוי המשתמש לבין ההחלטה מה מותר לו לראות. מסך התחברות יכול לזהות את דנה בהצלחה, אבל מסד הנתונים עדיין צריך לאכוף שדנה תראה רק את ההזמנות שלה. אחד המנגנונים לכך הוא RLS, אבטחה ברמת הרשומה. לפי התיעוד הרשמי של Supabase, הרשאות קובעות אילו פעולות מותר לתפקיד מסוים לבצע בטבלה, ומדיניות RLS קובעת על אילו רשומות הפעולות יחולו. טבלה החשופה דרך המערכת בלי ההגנה הזאת יכולה להיות נגישה בהתאם להרשאות שניתנו. המשמעות המעשית פשוטה: גם אם הממשק מציג רק את הנתונים שלכם, צריך לוודא שההגבלה נאכפת במסד עצמו. הסתרת כפתור או מסך אינה תחליף להגבלת גישה למידע.
גם מציאת מפתח בקוד של האתר אינה מספיקה כדי לקבוע שיש דליפה. בדיקה נפרדת שפרסם Vlad Tkachenko בספטמבר, שכללה 30,998 אפליקציות שנבנו באמצעות כלי AI, מדגישה שמפתחות ציבוריים מסוימים, ובהם מפתח anon של Supabase, מיועדים להופיע בדפדפן. ההגנה אמורה להגיע מהכללים שמאחוריהם. באותה בדיקה נמצאו טבלאות Supabase פתוחות ב־2,096 אפליקציות, בעוד שמפתח service_role, בעל הרשאות רחבות, הופיע בשלוש בלבד. אלה ממצאים ממדגם אחר, שאי אפשר לחבר למספרי UpGuard או להציג כשיעור הדליפות בכל השוק. אבל הם מחדדים נקודה שימושית: בדיקה שמחפשת רק סודות שנשכחו בקוד עלולה להחמיץ מערכת שהמפתחות בה תקינים וההרשאות שלה רחבות מדי.
המשמעות העסקית, בניתוח שלנו, רלוונטית במיוחד ליזם או לעסק ישראלי שמזמין מערכת קטנה לניהול לקוחות, תורים או פניות. כלי AI יכולים להפוך פרויקט שפעם נדחה בגלל עלות הפיתוח למשהו שכדאי לנסות. אלא שכדאיות כלכלית אינה נמדדת רק בזמן שנדרש להציג הדגמה עובדת. אם המערכת עומדת לקבל מידע אמיתי, גם בדיקת הרשאות היא חלק מעלות ההקמה. הדגמה מוצלחת אינה בדיקת אבטחה: היא מוכיחה שהפעולה הרצויה אפשרית, ולא שהפעולות האסורות נחסמות. ההבחנה הזאת חשובה גם למי שקונה תוכנה מספק חיצוני. השאלה המועילה היא לא רק באיזה כלי נבנתה המערכת, אלא איזו בדיקה הראתה שמשתמש אחד אינו יכול לקרוא את המידע של אחר, ומה יכול לראות מי שלא התחבר כלל.
מכאן גם נגזרת בדיקת קבלה ברורה יותר למוצרים שנבנים במהירות: לצד מסלול ההרשמה, התשלום או שמירת הטופס, צריך לבדוק גם ניסיונות גישה שאמורים להיכשל. Supabase עצמה ממליצה בתיעוד לבדוק הרשאות לקריאה, הוספה, עדכון ומחיקה עבור משתמשים מחוברים ועבור גישה ללא התחברות. עבור בעל עסק, התוצאה הנדרשת היא ראיה שההגבלות עובדות, ולא רק הבטחה שהוגדרה אבטחה. אין בממצאים האלה בסיס לקבוע שכל אפליקציה שנכתבה בעזרת AI דולפת, או שכל מסד פתוח כבר נוצל לרעה. יש בהם סיבה טובה לעדכן את ההגדרה של מוצר מוכן: כזה שעושה את מה שביקשתם, וגם מונע מאחרים לעשות את מה שלא התכוונתם לאפשר. לפני שמביאים את הלקוח הבא, כדאי לבדוק מי עוד יכול להיכנס.
