מדריכים · אבטחה
רוב האפליקציות שנוצרו עם AI או Lovable יוצאות לאוויר עם אותם חורי אבטחה: הרשאות שנבדקות רק בדפדפן, אפס בקרה בצד השרת על מה שפונקציה מורשית לעשות, סודות בהישג יד של הלקוח, בלי מגבלות על מה שאוטומציה יכולה להוציא, ובלי בידוד בין הנתונים של לקוחות שונים. כל אחד מהם בלתי נראה בדמו ויקר מאוד עם משתמשים אמיתיים.
זה פרק האבטחה של המדריך המלא למעבר מאבטיפוס ב‑Lovable לפרודקשן, מורחב במה שאנחנו באמת מוצאים כשאפליקציות כאלה מגיעות אלינו.
החור הנפוץ ביותר הוא הרשאה שנקבעת ברמת המשתמש, בקוד הלקוח, בלי ששום דבר בצד השרת בודק אותה. הופתענו כמה אפליקציות שנוצרו ב‑Lovable חולקות בדיוק את הדפוס הזה. האפליקציה נראית תקינה כי הממשק מסתיר את מה שאסור לכם לראות. אבל להסתיר זה לא להגן: מי שפותח את ה‑developer console יכול לקרוא לאותן פונקציות עם פרמטרים אחרים ולהגיע לנתונים של אחרים.
התיקון משעמם ומוחלט. ההרשאה נאכפת בשרת, ו‑RLS נכנס על כל טבלה בבסיס הנתונים, כך שגם בדיקה שנעקפה פוגשת דלת נעולה.
מפתחות API ופרטי גישה שייכים לשרת, נקודה. כשמפתח נשלח בתוך קוד הלקוח, כל מי שפותח את מקור העמוד מחזיק בו, ואיתו בבסיס הנתונים שלכם, בתקציב ה‑AI או בספק הסליקה. מערכות פרודקשן שומרות סודות בצד השרת בלבד ומאמתות webhooks של תשלומים בחתימה, כדי שאי אפשר יהיה לזייף אותם.
פיצ׳רים של AI מוציאים כסף בכל קריאה, ואפליקציות שנוצרו אוטומטית כמעט אף פעם לא מגבילות אותם. לקוח אחד הריץ אפליקציה אוטומטית לבניית אתרים בלי תקרה על עבודות במקביל, בלי מגבלות הוצאה ובלי כפתור עצירה אמיתי. יום אחד ללא השגחה הפיק חשבון AI של יותר מ‑1,000 דולר. האפליקציה עבדה בדיוק כמו שנבנתה. אף אחד לא בנה בלמים.
הגבלת קצב על נקודות קצה רגישות, תקרות לכל עבודה וכפתור עצירה שעובד הם לא תוספת יוקרה. הם ההבדל בין חשבונית מפתיעה ללא‑אירוע.
אם המוצר שלכם משרת יותר מלקוח אחד, כל אחד מהם חייב להגיע רק לנתונים של עצמו, ובסיס הנתונים עצמו חייב לאכוף את זה. באפליקציות שנוצרו אוטומטית הגבול הזה בדרך כלל לא קיים; הנתונים של כל לקוח נמצאים במרחק שאילתה אחת מהנתונים של כל האחרים. אנחנו מאמתים בידוד לפני כל שחרור בבדיקות צולבות עם שני חשבונות אמיתיים, כי הבטחה בקוד היא לא הוכחה.
רשימת ההקשחה קצרה לכתיבה וארוכה לביצוע: RLS על כל טבלה, בדיקות הרשאה בצד השרת, סודות בשרת בלבד, אימות חתימה ל‑webhooks, הגבלת קצב, אימות דו‑שלבי למנהלים, ויומן ביקורת שמאפשר להתחקות אחרי פעולות רגישות. זה אחד מששת תחומי ההנדסה שמכוסים בכל בנייה, והעומק גדל עם הרמה שבוחרים.
רוצים לדעת אם האפליקציה שלכם סובלת מהחורים האלה? הצעד הראשון הכן הוא שיחת אפיון. תשובות ישירות לשאלות שמייסדים שואלים לפני שהם מוסרים לנו אבטיפוס נמצאות בעמוד השאלות והתשובות.
מייסד והמפתח הראשי של Zyntari. בונה אפליקציות ופתרונות AI מאז 2024; לפני כן, 12 שנים במכירות וניהול תיקי לקוחות ושותף‑מייסד בשתי חברות. עוד על הצוות · LinkedIn