אבטחה ופרטיות ב־Vibe Coding: מדריך לפני העלייה לפרודקשן
האפליקציה עובדת — אבל האם הנתונים באמת מוגנים? מדריך מעשי לסודות, הרשאות, מידע אישי וכלי AI לפני שמכניסים משתמשים אמיתיים.
אפליקציה שנבנתה ב־Vibe Coding יכולה להיראות מצוין ובו בזמן לחשוף מידע אישי דרך טבלה לא מוגנת במסד הנתונים, נקודת קצה ללא אימות או קובץ סביבה שנכלל בהקשר של כלי AI. הסיכון אינו מוגבל לקוד: הוא תלוי גם במידע שהמערכת אוספת, במי שיכול לגשת אליו ובמה שנשלח לספקי AI במהלך הפיתוח.
במדריך הזה נבדוק את שכבות האבטחה והפרטיות החשובות לפני שמעלים לפרודקשן מוצר שנבנה בעזרת Cursor, Lovable, Bolt, Replit, Claude Code או כלי דומה.
המאמר מספק עקרונות הנדסיים כלליים ואינו תחליף לייעוץ משפטי או לבדיקת ציות המותאמת לארגון.
פרטיות מתחילה במפת מידע, לא במסך הסכמה
לפני שמפעילים סורק אבטחה, צריך לדעת איזה מידע קיים במערכת. הכינו רשימה קצרה לכל שדה או מסמך רגיש:
| שאלה | דוגמה לתשובה |
|---|---|
| מה נאסף? | שם, טלפון, כתובת IP, תוכן שיחה |
| למה הוא נדרש? | פתיחת חשבון, תמיכה או אספקת שירות |
| היכן הוא נשמר? | מסד נתונים, לוגים, מערכת דיוור |
| מי יכול לראות אותו? | המשתמש, צוות תמיכה, מנהל מערכת |
| למי הוא נשלח? | ספק אחסון, ספק AI, כלי אנליטיקה |
| מתי הוא נמחק? | לאחר סגירת חשבון או תקופת שמירה מוגדרת |
אם אין תשובה לשאלה “למה אנחנו צריכים את המידע הזה?”, ברירת המחדל הנכונה היא לא לאסוף אותו. צמצום מידע מפחית גם את הנזק האפשרי במקרה של תקלה.
בישראל, תקנות הגנת הפרטיות (אבטחת מידע) חלות על מאגרים העונים על הגדרת מאגר מידע בחוק, לרבות מאגרים הכוללים מידע שנאסף ממקורות פומביים. לכן “המידע כבר נמצא באינטרנט” אינו פוטר אוטומטית מאחריות.
סכנה שקטה: המידע שכלי ה־AI רואה בזמן הפיתוח
עוזר קוד אינו בהכרח רואה רק את השורה שעליה אתם עובדים. בהתאם לכלי ולהגדרות, הוא עשוי לקבל קבצים פתוחים, מבנה פרויקט, פלט מהטרמינל או קטעים נוספים מהמאגר.
מדריך Secure Coding with AI של OWASP ממליץ לבדוק איזה הקשר נשלח לספק, להחריג קבצים רגישים ולא להניח ש־.gitignore מונע מכלי AI לקרוא אותם.
לפני תחילת העבודה:
- החריגו קובצי
.env, מפתחות פרטיים, קובצי פרטי גישה וקבצים שיוצאו ממערכות לקוחות מההקשר של כלי ה־AI; - אל תדביקו טוקנים, סיסמאות או מידע אישי בפרומפט;
- בדקו את הגדרות שמירת הנתונים והאימון של הספק;
- השתמשו בנתוני בדיקה סינתטיים במקום בנתוני ייצור;
- הגדירו אילו מאגרים מותר לפתוח בכלי ענן ואילו דורשים סביבת פיתוח מבודדת.
שש בדיקות אבטחה שחייבים להשלים
1. סודות אינם מגיעים לדפדפן
ערכים המוטמעים בקוד צד הלקוח נגישים לכל מי שמקבל אותו. מפתח service_role של Supabase, סוד webhook או מפתח סודי אחר בעל הרשאות מיוחדות חייבים להישאר בצד השרת או במנהל סודות. מפתחות ציבוריים המיועדים לצד הלקוח הם מקרה אחר: יש לגבות אותם באכיפת הרשאות תקינה.
אם מפתח רגיש כבר הופיע ב־commit, בקובץ שנפרס או בשיחת AI — אל תסתפקו במחיקתו. החליפו אותו, צמצמו את הרשאותיו ובדקו בלוגים אם נעשה בו שימוש.
2. הרשאות נאכפות בצד השרת
הסתרת כפתור “ניהול” אינה מנגנון הרשאה. יש לאכוף כללי גישה בכל פעולת API מוגנת ובכל שאילתת נתונים מוגנת. ב־Supabase יש להפעיל Row Level Security בטבלאות שנחשפות דרך ה־Data API ולהגדיר מדיניות לפעולות המותרות. פרטי גישה של השרת שעוקפים את המדיניות הזאת דורשים בדיקות הרשאה נפרדות.
בדקו כל פעולה בשלושה מצבים: ללא התחברות, כמשתמש רגיל וכמשתמש בעל הרשאות ניהול. נסו גם לגשת לרשומה של משתמש אחר באמצעות שינוי מזהה בבקשה.
3. קלט לא מהימן נשאר לא מהימן
יש לאמת סוג, אורך וטווח בצד השרת, להשתמש בשאילתות פרמטריות, לקודד פלט לפי ההקשר ולהגביל העלאות קבצים. בקשה מהמודל “לנקות את הקלט” אינה תחליף לכללים מפורשים ולבדיקות.
4. לוגים עוזרים בלי להפוך למאגר רגיש נוסף
לוג טוב מתעד זמן, פעולה, מזהה בקשה ותוצאה. הוא לא צריך להכיל סיסמאות, טוקנים, מספרי כרטיס או תוכן אישי מלא.
הגדירו מראש אילו שדות יוסתרו, מי רשאי לצפות בלוגים ומתי הם יימחקו. בדקו גם את הלוגים של ספקי צד שלישי ולא רק את אלה שבקוד שלכם.
5. תלויות ושרשרת האספקה נסרקות
כלי AI עשויים להציע חבילה לא מוכרת כדי לפתור בעיה במהירות. לפני שמוסיפים תלות, בודקים את המקור, התחזוקה, הרישיון וההרשאות שהיא דורשת. ב־CI מוסיפים סריקת תלויות וסודות וחוסמים ממצאים קריטיים.
6. לקוד קריטי יש אחראי אנושי
OWASP ממליץ שלא לאפשר לאותו סוכן AI גם לכתוב רכיב אבטחה וגם לספק את ההוכחה היחידה שהוא תקין. אימות זהות, הרשאות, הצפנה וטיפול במידע אישי דורשים ביקורת אנושית ובדיקות עצמאיות.
פרטיות כחלק מהתהליך
אבטחה מגינה על מידע מפני גישה לא מורשית. פרטיות עוסקת גם במידע שמותר לאסוף ובשימושים המותרים בו. לכן כדאי לנהל פעולות רגישות בתהליך שניתן לעקוב אחריו ולבקר אותו:
- בקשת המשתמש מתקבלת ומתועדת.
- זהות המבקש וההרשאה שלו מאומתות.
- נאספים רק הנתונים הנדרשים לביצוע.
- פעולה חריגה עוברת אישור אנושי.
- התוצאה ותקופת שמירת המידע מתועדות.
- מחיקה או תיקון מבוצעים בכל המערכות הרלוונטיות.
זו נקודת החיבור לגישת Process-First: ה־AI יכול לסווג, לסכם או להציע פעולה, אבל ההרשאה, נקודת הבקרה ותיעוד ההחלטה נשארים בתוך תהליך נשלט.
צ’קליסט קצר לפני פרודקשן
- קיימת מפת מידע וסיבה עסקית לאיסוף כל פריט מידע אישי.
- אין נתוני ייצור, סודות או מפתחות בהקשר של כלי ה־AI.
- כל הרשאה נאכפת בשרת ובשכבת הנתונים.
- מפתחות שנחשפו הוחלפו ולא רק נמחקו מהקוד.
- לוגים אינם מכילים תוכן רגיש מיותר.
- קיימות סריקות סודות, תלויות וקוד בצינור ה־CI.
- תרחישי גישה בין משתמשים נבדקו ידנית ואוטומטית.
- יש אחראי אנושי לקוד ותהליך מוגדר לתגובה לאירוע.
- קיימת מדיניות שמירה ומחיקה שניתנת לביצוע בפועל.
סיכום
אבטחה ופרטיות אינן שכבת גימור שמוסיפים אחרי שה־Vibe Coding הסתיים. הן חלק מהארכיטקטורה: איזה מידע נכנס, איזה הקשר רואה ה־AI, מי רשאי לבצע פעולה ואיזו בדיקה חוסמת טעות לפני הפריסה.
אם האפליקציה כבר פעילה ואתם לא בטוחים איפה נשמר מידע רגיש או מי יכול לגשת אליו, התחילו במדריך החילוץ המלא ובדקו את שירות Vibe Coding Rescue. אפשר גם לפנות אלינו לבדיקה ממוקדת.
מקורות והמשך קריאה: