איך מאבטחים אפליקציית וייב קודינג לפני שמשתפים אותה
בקצרה
לפני שעמיתים משתמשים באפליקציה שבניתם עם AI, בודקים קודם ארבעה דברים: אף אחד לא עובר בלי התחברות של החברה, רק חשבונות של החברה נכנסים, אין מפתחות בקוד שרץ בדפדפן, ואי אפשר לקרוא את מסד הנתונים בלי לעבור דרך האפליקציה. אחר כך בודקים מי יכול לעשות מה בתוכה, ומי הבעלים שלה כשאתם עוזבים.
רוב הדליפות מאפליקציות שנבנו עם AI הן לא מתקפות מתוחכמות. אלה דלתות פתוחות: קישור ציבורי, מסד נתונים שהחוקים שלו כבויים, מפתח בתוך הדף. רשימת הבדיקה הזאת מיועדת למי שבנה את האפליקציה ולאיש ה-IT שבודק אותה. כל סעיף מסביר מה משתבש, איך בודקים את זה במילים פשוטות, ומה TeamOnly מטפלת בו ומה עדיין באחריותכם.
עודכן לאחרונה נכתב על ידי TeamOnly. אנחנו מארחים אפליקציות פנימיות שנבנו עם AI, וכל סעיף אומר בכנות איפה אנחנו עוזרים ואיפה לא.
01למה זה חשוב
מה משתבש באפליקציות שנבנו עם AI
כלי AI טובים בלגרום לאפליקציה לעבוד. הם פחות זהירים לגבי מי עוד יכול להשתמש בה. שלושה ממצאים מהשנתיים האחרונות מראים את הדפוס.
380,000
נכסים נגישים לציבור ב-Lovable, Base44, Netlify ו-Replit שמצאה חברת האבטחה Red Access במאי 2026. כ-5,000 מהם החזיקו נתונים רגישים של חברות, ורבים אונדקסו ב-Google.
170 מתוך 1,645
אפליקציות Lovable שנבדקו במרץ 2025 אפשרו לכל אחד לקרוא או לשנות נתונים במסד הנתונים שלהן ב-Supabase בלי להתחבר, כי חוקי הגישה למסד הנתונים היו חסרים או שגויים (CVE-2025-48757).
205,474
שמות חבילות מומצאים ש-16 מודלים של AI הציעו ב-576,000 דוגמאות קוד, במחקר מ-2025. תוקפים יכולים לפרסם חבילות בשמות האלה ולחכות שמישהו יתקין אותן.
אף אחד מאלה לא דרש תוקף מתוחכם. הדלתות היו פתוחות. וזו בשורה טובה: קל לבדוק אם יש דלתות פתוחות, ולא צריך לקרוא קוד כדי לעשות את זה.
עושים אותן לפי הסדר. הראשונות משאירות זרים בחוץ, האחרונות תופסות טעויות בתוך החברה.
שום דבר לא נטען לפני התחברות של החברה
מה משתבש
כלי AI בונים לעתים קרובות את מסך ההתחברות כדף אחד באפליקציה. שאר האפליקציה, וה-API שלה, עדיין עונים לכל מי שמדלג על הדף הזה או קורא ל-API ישירות. Red Access מצאה אפליקציות של חברות שנתנו גישת אדמין לכל מי שהגיע לכתובת.
בודקים בעצמכם
פותחים את האפליקציה בחלון גלישה פרטית. אמור להופיע מסך התחברות ותו לא. אחר כך שואלים את כלי ה-AI: „תפרט את כל נתיבי ה-API ותגיד לי אילו מהם עובדים בלי התחברות.” התשובה צריכה להיות אף אחד.
ב-TeamOnly
מטופל. כל בקשה לכל אפליקציה נבדקת לפני שקוד כלשהו שלכם רץ, כולל קריאות API, שמקבלות 401 בלי סשן. אין הגדרה שהופכת אפליקציה לציבורית.
רק חשבונות של החברה נכנסים
מה משתבש
„Sign in with Google” מכניס כברירת מחדל כל חשבון Google, כולל Gmail פרטי. ההגדרה hd של Google רק מצמצמת את בוחר החשבונות, ו-Google מזהירה לא לסמוך עליה כי אפשר לשנות את הבקשה. את הדומיין צריך לבדוק בשרת.
בודקים בעצמכם
מנסים להתחבר עם חשבון Gmail או Outlook פרטי. אמורים לקבל סירוב. שואלים את כלי ה-AI איפה השרת בודק את הדומיין של המייל, והאם הוא בודק את הטוקן החתום מ-Google או ערך שהדפדפן שלח.
ב-TeamOnly
מטופל. העמיתים מתחברים עם Google של העבודה, Microsoft של העבודה או קוד שנשלח למייל העבודה. הדומיין בטוקן ההתחברות המאומת נבדק מול הדומיינים של החברה, וחשבונות פרטיים נדחים.
רק האנשים הנכונים בתוך החברה
מה משתבש
אפליקציה עם משכורות, הערכות עובדים או נתוני לקוחות משותפת עם כל החברה כי זו הייתה ברירת המחדל. או שה-AI בונה רשימת הרשאות משלו בתוך הקוד, שאף אחד לא מעדכן.
בודקים בעצמכם
שואלים: האם כל החברה צריכה לראות את הנתונים האלה? אם לא, כותבים את שמות האנשים שצריכים, ובודקים שמישהו מחוץ לרשימה נדחה.
ב-TeamOnly
מטופל, ואתם בוחרים. הגישה היא לכל החברה או לרשימה של אנשים מסוימים, בדשבורד או עם npx teamonly access only priya@acme.com. היא נבדקת בכל בקשה, כך שהסרה של מישהו נכנסת לתוקף תוך דקה.
לא בקישור ציבורי, לא בתוצאות חיפוש
מה משתבש
חלק מהכלים לבניית אפליקציות מפרסמים לכתובת ציבורית אלא אם בוחרים פרטי. אפליקציות ציבוריות נמצאות: Red Access דיווחה שרבות מאפליקציות החברות החשופות אונדקסו ב-Google ובמנועי חיפוש אחרים.
בודקים בעצמכם
מחפשים ב-Google את site: ואחריו את הכתובת של האפליקציה. בודקים את הגדרת החשיפה של הפרויקט בפלטפורמה שבה בניתם אותו. אם כתוב ציבורי, משנים את זה לפני כל דבר אחר.
ב-TeamOnly
מטופל. האפליקציות יושבות בכתובת yourapp.yourcompany.teamonly.app מאחורי מסך ההתחברות. כל תשובה, כולל מסך ההתחברות, אומרת למנועי חיפוש לא לאנדקס, ומסך ההתחברות מציג רק את שם האפליקציה ואת דרכי ההתחברות.
אין מפתחות בקוד שרץ בדפדפן
מה משתבש
כלי AI שמים מפתחות API בקוד ה-React או במשתנים שמתחילים ב-VITE_ או ב-NEXT_PUBLIC_. כל מה שנשלח לדפדפן קריא לכל מי שפותח את האפליקציה. Supabase אומרת שהמפתח הסודי שלה אסור שיהיה בדפדפן אף פעם, כי הוא עוקף את כל חוקי מסד הנתונים.
בודקים בעצמכם
שואלים את כלי ה-AI: „יש מפתח, טוקן או סיסמה בקוד הפרונט, במשתנה VITE_ או בקובץ .env שנכנס ל-commit?” בדפדפן פותחים את כלי המפתחים ומחפשים בקבצים שנטענו את key, secret ו-sk_. אם מפתח נחשף אי פעם, מחליפים אותו בשירות שהנפיק אותו.
ב-TeamOnly
מטופל חלקית. המפתחות נשמרים עם npx teamonly secrets set NAME, מחוץ לקוד, ורק קוד השרת של האפליקציה יכול לקרוא אותם. ההוראות ש-TeamOnly מוסיפה אומרות לכלי ה-AI לא להשתמש אף פעם במפתחות VITE_. שום דבר לא מונע מכם להדביק מפתח לקוד בעצמכם, אז עדיין בודקים.
אי אפשר לקרוא את מסד הנתונים בעקיפת האפליקציה
מה משתבש
ב-Supabase ובשירותים דומים, הדפדפן מדבר ישירות עם מסד הנתונים, וחוקי גישה (row-level security) קובעים מה הוא יכול לראות. כשהחוקים האלה כבויים או שגויים, כל מי שיש לו את המפתח הציבורי יכול לקרוא או לשנות טבלאות שלמות. זה היה הממצא של Lovable.
בודקים בעצמכם
ב-Supabase פותחים את Advisors, ואז את Security Advisor. כל שגיאת „RLS disabled in public” פירושה טבלה שכל אחד יכול לקרוא. לא מספיק שיש חוק: מתחברים כעמית רגיל ומנסים לפתוח רשומה של מישהו אחר.
ב-TeamOnly
מטופל מול אנשים מבחוץ. למסד הנתונים של כל אפליקציה אין כתובת משלו באינטרנט. אפשר להגיע אליו רק דרך קוד השרת של האפליקציה, אחרי התחברות. אילו שורות כל אדם מחובר רשאי לראות, את זה הקוד של האפליקציה עדיין צריך לעשות נכון (ראו בדיקה 8).
הנתונים של כל אפליקציה נפרדים
מה משתבש
כמה אפליקציות חולקות מסד נתונים אחד או bucket אחסון אחד כי זה היה מהיר יותר. ואז מפתח או באג באפליקציה אחת פותחים את כולן.
בודקים בעצמכם
שואלים: האם אפליקציה אחרת משתמשת באותו מסד נתונים, אחסון או מפתחות כמו זו? אם כן, האפליקציה החלשה ביותר קובעת כמה בטוחות כולן.
ב-TeamOnly
מטופל. כל אפליקציה מקבלת מסד נתונים, אחסון קבצים וסודות משלה בפריסה הראשונה, ועוגיית הסשן שלה קשורה לכתובת שלה. אפליקציות לא יכולות להגיע לנתונים של אחרות.
מי יכול לעשות מה, נבדק בשרת
מה משתבש
ה-AI מסתיר את כפתור האישור מרוב האנשים אבל משאיר את נתיב האישור פתוח לכל מי שמחובר. או שהשרת סומך על תפקיד או מייל שהדפדפן שולח. בקרת גישה פגומה (Broken access control) היא מספר אחת ב-OWASP Top 10. קלט שלא נבדק הוא בן דוד שלה: סכום שלילי, שאילתת SQL שנבנית מתיבת טקסט.
בודקים בעצמכם
מתחברים כעמית רגיל ומנסים לעשות מה שרק מנהלים אמורים. שואלים את כלי ה-AI: „בכל נתיב API, מי רשאי לקרוא לו, ואיפה בשרת זה נבדק? כל השאילתות למסד הנתונים משתמשות ב-placeholders?”
ב-TeamOnly
מטופל חלקית. האפליקציה מקבלת את האדם המאומת (ctx.user) ואת התפקידים שמחלקים בדשבורד (ctx.user.roles), וכותרות זהות מזויפות מוסרות. ההוראות אומרות לכלי ה-AI להשתמש ב-placeholders בשאילתות ולבדוק קלט בשרת. בדיקת התפקיד בכל נתיב היא הקוד של האפליקציה שלכם. TeamOnly לא בודקת אותו.
כל חבילה אמיתית ונחוצה
מה משתבש
כלי AI מציעים לפעמים חבילות שלא קיימות. תוקפים מפרסמים חבילות בשמות האלה, כך שהתקנה של אחת מהן מריצה קוד של זר בתוך האפליקציה.
בודקים בעצמכם
פותחים את package.json. כל שם שלא מכירים, מחפשים ב-npmjs.com: לחבילה אמיתית יש היסטוריה, מאגר קוד מקושר והורדות קבועות. מריצים npm audit לפני הפריסה, ומסירים חבילות שהאפליקציה כבר לא משתמשת בהן.
ב-TeamOnly
לא מטופל. TeamOnly לא סורקת חבילות. אפליקציה יכולה להגיע רק לנתונים ולמפתחות של עצמה, וזה מגביל במה חבילה זדונית יכולה לגעת, אבל בתוך האפליקציה הזאת היא עדיין יכולה לקרוא הכול.
תיעוד של מי שינה מה
מה משתבש
משהו מאושר, נמחק או משתנה ואף אחד לא יודע להגיד מי עשה את זה. אפליקציות שנבנו עם AI כמעט אף פעם לא שומרות היסטוריה אלא אם מבקשים.
בודקים בעצמכם
מבקשים מכלי ה-AI לתעד מי יצר ומי שינה לאחרונה כל רשומה, ומתי, ולשמור טבלת היסטוריה לאישורים ולמחיקות. מנסים: משנים רשומה, ואז מחפשים עליה את השם שלכם.
ב-TeamOnly
מטופל חלקית. הדשבורד מציג כל פריסה של כל אפליקציה, עם מי פרס ומתי, ולוגים בזמן אמת. הלוגים הם בזמן אמת, לא נשמרים. יומני ביקורת של התחברויות ושינויי גישה כלולים במסלול Business, ומוגדרים יחד איתכם. היסטוריה בתוך האפליקציה (מי אישר הוצאה) היא התפקיד של האפליקציה.
בעלים, גיבוי ותוכנית למי שעוזב
מה משתבש
הבונה עוזב והאפליקציה ממשיכה לרוץ על החשבון הפרטי שלו, או נעצרת כשהכרטיס שלו מבוטל. או ששינוי גרוע מוחק טבלה ואין עותק.
בודקים בעצמכם
כותבים מי הבעלים של האפליקציה ומי מחליף אותו. שומרים את הקוד במאגר Git של החברה. מבקשים מכלי ה-AI להוסיף ייצוא CSV של הטבלאות העיקריות, ומנסים אותו.
ב-TeamOnly
מטופל חלקית. האפליקציות שייכות לחברה, ואדמינים יכולים להעביר אפליקציה לבעלים חדשים. השבתת חשבון העבודה של מישהו עוצרת התחברויות חדשות. מי שכבר מחובר נשאר בפנים עד שהסשן שלו נגמר, ואדמינים בוחרים כמה זמן זה, בין 8 שעות ל-30 ימים. כרגע אין בדשבורד כפתור גיבוי או ייצוא, אז בונים את הייצוא לתוך האפליקציה.
03להדפסה
הבדיקה של דקה אחת
אחת־עשרה שאלות של כן או לא. כל „לא” הוא הדבר הבא לתקן.
לפני שמשתפים את האפליקציה
חלון גלישה פרטית מציג התחברות של החברה ותו לא.
חשבון Gmail או Outlook פרטי נדחה.
רק מי שצריך את הנתונים האלה יכול לפתוח את האפליקציה.
חיפוש site: של כתובת האפליקציה לא מוצא כלום.
אין מפתח, טוקן או סיסמה בקוד הדפדפן או במאגר.
אי אפשר להגיע למסד הנתונים בלי לעבור דרך האפליקציה.
הנתונים והמפתחות של האפליקציה לא משותפים עם אף אפליקציה אחרת.
עמית רגיל לא יכול לעשות מה שרק מנהלים אמורים.
כל חבילה ב-package.json אמיתית ועדיין בשימוש.
ברשומות רואים מי יצר ומי שינה אותן.
מישהו אחר יודע שהוא הבעלים של האפליקציה אם אעזוב, ואפשר לייצא את הנתונים.
רבע שעה עם הבונה, עם שיתוף מסך. בודקים את ההגדרות, לא קוראים כל שורת קוד.
איפה היא יושבת ומי יכול להגיע אליה
מבקשים את הכתובת. פותחים אותה ממכשיר שלא מחובר, ומחשבון פרטי. שואלים איזו פלטפורמה מארחת אותה ומאיזה חשבון משלמים עליה. חשבון פרטי הוא הדבר הראשון שצריך לשנות.
אילו נתונים היא מחזיקה
שואלים מה נכנס לאפליקציה ומאיפה זה מגיע. מידע אישי של לקוחות, נתוני תשלום, מידע רפואי או סיסמאות למערכות אחרות מעלים את הרף, ואולי מחייבים להגביל את האפליקציה לרשימה של אנשים מסוימים.
איפה המפתחות
מפרטים כל שירות חיצוני שהאפליקציה קוראת לו. כל מפתח צריך להיות בהגדרות הסודות של ספק האחסון, מוגבל למה שהאפליקציה צריכה, ולא משותף עם אפליקציות אחרות. מחליפים כל מפתח שהיה אי פעם בקוד או בצ׳אט.
מי יכול לעשות מה
מבקשים מהבונה להתחבר כמשתמש רגיל, או מבקשים מעמית, ומנסים את פעולות האדמין. מבקשים מהבונה שכלי ה-AI שלו יפרט כל נתיב API ואיפה הוא בודק את התפקיד. פערים כאן מתקנים בקוד של האפליקציה.
חבילות וקוד
עוברים יחד על package.json ומריצים npm audit. מבקשים שהקוד יישמר במאגר Git של החברה, לא רק בלפטופ של הבונה.
הבעלים, והיום שבו הוא עוזב
רושמים ברשימת האפליקציות את האפליקציה, הבעלים, בעלים מחליף, הנתונים והמשתמשים שלה. מסכימים מה קורה כשהבעלים עוזב. במדריך אפליקציות ה-Shadow AI יש מדיניות של עמוד אחד שאפשר להעתיק.
זה יכול להיות בטוח. הבעיות הנפוצות קשורות למקום שבו האפליקציה יושבת ולאופן שבו היא הוגדרה: קישור ציבורי, אין התחברות אמיתית, מפתחות בדפדפן, חוקי מסד הנתונים כבויים. את כל אחת מהן אפשר לבדוק בכמה דקות. עוברים על רשימת הבדיקה בדף הזה לפני ששולחים את הקישור.
מה סיכון האבטחה הגדול ביותר באפליקציית וייב קודינג?
נתונים שכל אחד יכול להגיע אליהם בלי להתחבר. זה קורה בדרך כלל באחת משתי דרכים: האפליקציה נמצאת בקישור ציבורי בלי התחברות לפניה, או שמסד הנתונים עונה ישירות לבקשות וחוקי הגישה שלו כבויים (row-level security ב-Supabase). שתיהן עניין של הגדרה, לא של AI שכותב קוד גרוע.
האם בטוח לשים את מפתח ה-anon של Supabase בדפדפן?
מפתח ה-anon או ה-publishable נועד להיות בדפדפן, אבל רק כי row-level security מגביל למה הוא יכול להגיע. אם row-level security כבוי בטבלה, כל מי שיש לו את המפתח יכול לקרוא ולשנות אותה. המפתח הסודי או מפתח ה-service_role אסור שיהיה בדפדפן אף פעם: הוא עוקף את כל החוקים.
האם „Sign in with Google” מגביל אפליקציה לחברה שלי?
לא לבד. כברירת מחדל כל חשבון Google יכול להתחבר, כולל Gmail פרטי. ההגדרה hd של Google רק מצמצמת את בוחר החשבונות, ו-Google אומרת לא לסמוך עליה. השרת של האפליקציה צריך לבדוק את הדומיין בטוקן ההתחברות המאומת בכל בקשה.
איך בודקים אם Google אינדקס את האפליקציה שלי?
מחפשים ב-Google את site: ואחריו את הכתובת של האפליקציה, למשל site:myapp.lovable.app. אם מופיעים דפים, האפליקציה ציבורית ומאונדקסת. הופכים את האפליקציה לפרטית או מעבירים אותה אל מאחורי התחברות של החברה, ואז מבקשים מ-Google להסיר את הדפים עם הכלי Removals ב-Search Console, אם הדומיין שלכם.
כדאי להגיד לכלי ה-AI לכתוב קוד מאובטח?
כן, ועדיף לתת לו הוראות קבועות מאשר לבקש פעם אחת. קובץ rules בפרויקט (CLAUDE.md, AGENTS.md או rule של Cursor) אומר לכלי איפה שמים מפתחות, איך כותבים שאילתות למסד הנתונים ואיפה בודקים תפקידים. npx teamonly init מוסיף אותם לאפליקציות TeamOnly. ואחר כך עדיין מריצים את הבדיקות בעצמכם: הוראות מצמצמות טעויות, הן לא מעלימות אותן.
האם TeamOnly סורקת את הקוד של האפליקציה שלי לבעיות אבטחה?
לא. TeamOnly שמה התחברות של החברה לפני כל אפליקציה, מפרידה בין הנתונים והמפתחות של כל אפליקציה, ומרחיקה את האפליקציות ממנועי חיפוש. היא לא בודקת את הקוד, לא סורקת את החבילות ולא בודקת את החוקים בתוך האפליקציה. הסעיפים האלה ברשימה עדיין באחריותכם.
מה ה-IT צריך לבדוק לפני שמאשרים אפליקציה שנבנתה עם AI?
איפה היא מתארחת ומי יכול להגיע אליה, איך ההתחברות מוגבלת, איפה המפתחות, אילו נתונים היא מחזיקה, מי הבעלים, ומה קורה כשהאדם הזה עוזב. החלק „ל-IT” בדף הזה הוא סקירה קצרה שאפשר לעשות ב-15 דקות עם הבונה.