📚 בית הספר ל-AI 🧑‍💻 מפתחים ומתקדמיםבינוני⏱ 13 דק' קריאהחינם

בניתם ב-Vibe Coding? בדיקת האבטחה שעושים עם Claude ו-GPT-6 לפני שעולים לאוויר

תהליך מעשי בן שלושה שלבים לאיתור מפתחות API חשופים, מסד נתונים פתוח ודליפת פרטי משתמשים, עם פרומפטים מוכנים להעתקה. כולל הקווים האדומים שמעבר להם חייבים מפתח אנושי.

✍️ מערכת הבלטרעודכן 14 בנובמבר 2026

בניתם אפליקציה או אתר בעזרת Claude, ChatGPT, Gemini או כלי בנייה דומה, הכול עובד, ואתם רגע לפני שליחת הקישור לעולם. המדריך הזה מיועד לרגע הזה, ובמיוחד למי שאינו מפתח במקצועו: יזמים, בעלי עסקים, מעצבים ואנשי מוצר שהגיעו למוצר עובד בלי לכתוב את רוב הקוד בעצמם.

מודל שמתבקש “לבנות לי אפליקציה” מתמקד בכך שהיא תעבוד, ולא בכך שהיא תהיה סגורה. התוצאה היא שלושה כשלים שחוזרים שוב ושוב: מפתח API שיושב בקוד שנשלח לדפדפן, מסד נתונים שכל אחד יכול לקרוא, ונתוני משתמשים שזולגים בין חשבונות. את רובם אפשר למצוא בערב אחד, בעזרת אותם מודלים שבנו את האפליקציה, אם יודעים מה לשאול ואיך לאמת את התשובה.

המדריך לא יהפוך אתכם לחוקרי אבטחה, והוא לא תחליף לבדיקה מקצועית במקומות שבהם היא נדרשת. הוא יעזור לכם לסגור את החורים הנפוצים ולזהות מתי הגעתם לגבול היכולת שלכם.

למה דווקא אפליקציות Vibe Coding דולפות

כדאי להבין את המנגנון, כי הוא מסביר איפה לחפש:

המודל פותר את הבעיה שהצגתם. כתבתם “זה לא מצליח לשמור למסד הנתונים”, והדרך הקצרה ביותר לפתור את זה היא לפעמים לבטל את ההרשאות. השגיאה נעלמת ואתם ממשיכים הלאה.
סביבת הפיתוח סלחנית. מסדי נתונים רבים נפתחים ב“מצב בדיקה” שמאפשר הכול. אם אף אחד לא סוגר אותו לפני ההשקה, הוא נשאר פתוח.
אין לכם דרך לראות את מה שלא ביקשתם. אפליקציה פרוצה נראית ומתנהגת בדיוק כמו אפליקציה מאובטחת, עד שמישהו בודק.

לכן שאלה כמו “האם האפליקציה שלי מאובטחת?” כמעט חסרת ערך. המודל יענה תשובה כללית ומרגיעה. העבודה האמיתית היא לבדוק שלושה דברים מוגדרים, אחד אחרי השני.

שלב 1: מפתחות API חשופים

מפתח API הוא סיסמה לשירות חיצוני: מודל שפה, סליקה, שליחת מיילים או SMS. מי שמחזיק בו יכול להשתמש בשירות על חשבונכם, ולעיתים גם לגשת לנתונים.

הכלל הבסיסי: כל מה שנשלח לדפדפן או נארז בתוך אפליקציית מובייל הוא ציבורי. מפתח סודי צריך לחיות רק בצד השרת.

איפה מפתחות מסתתרים בפועל:

בקוד צד הלקוח. משתני סביבה עם התחיליות NEXT_PUBLIC_, VITE_ או EXPO_PUBLIC_ נכנסים לקוד שמגיע למשתמש. זו המשמעות של התחילית. מפתח סודי עם תחילית כזו חשוף גם אם הוא יושב בקובץ .env.
בהיסטוריית Git. מחקתם את המפתח מהקוד? הוא עדיין קיים בקומיטים הקודמים. אם המאגר ציבורי או היה ציבורי אי פעם, המפתח נחשב דלוף.
בקובץ .env שנכנס למאגר כי אף אחד לא הוסיף אותו ל-.gitignore.
בצילומי מסך, בקובצי README ובשיחות ששיתפתם.

בדיקה ידנית של חמש דקות: פתחו את האתר החי, לחצו F12, עברו ללשונית Network, רעננו את הדף והשתמשו בחיפוש כדי לחפש תחיליות מוכרות של מפתחות (למשל sk-), את המילים secret, key, token, ואת שם השירות שאתם משלמים עליו. אם מצאתם שם מפתח סודי, גם אחרים ימצאו.

בדיקה של ההיסטוריה בטרמינל:

git log -p --all -S "sk-" | head -50
git ls-files | grep -i "\.env"

ואז הפרומפט לסוכן הקוד (Claude Code או כל כלי שיש לו גישה לקבצים):

עבור על כל הפרויקט וחפש סודות חשופים. אני רוצה רשימה מדויקת, לא הערכה כללית.

בדוק:
1. מפתחות, טוקנים וסיסמאות שכתובים ישירות בקוד (כולל קבצי הגדרות, סקריפטים ובדיקות).
2. משתני סביבה עם תחילית שחושפת אותם ללקוח (NEXT_PUBLIC_, VITE_, EXPO_PUBLIC_) והאם הערך שלהם אמור להיות סודי.
3. האם קובצי .env נמצאים ב-.gitignore, והאם אחד מהם נכנס פעם להיסטוריית Git.
4. קריאות לשירותים חיצוניים שיוצאות ישירות מהדפדפן במקום דרך השרת.

לכל ממצא תן: קובץ ושורה, איזה שירות, מה אפשר לעשות עם המפתח הזה, ומה התיקון.
אל תציג את ערכי המפתחות עצמם, רק את ארבעת התווים הראשונים.
בסוף כתוב במפורש מה לא בדקת ולמה.

מצאתם מפתח חשוף? מחיקה מהקוד אינה מספיקה. הסדר הנכון הוא לבטל את המפתח בלוח הבקרה של השירות, להנפיק חדש, לשמור אותו כמשתנה סביבה בצד השרת, ורק אז לנקות את הקוד. באותה הזדמנות הגדירו תקרת הוצאה חודשית בכל שירות שמאפשר זאת. כך טעות עתידית תעלה לכם סכום קטן וידוע מראש.

שלב 2: מסד נתונים פתוח

זה הכשל היקר ביותר, והוא נפוץ בעיקר אצל מי שבנה על Supabase או Firebase, שם הדפדפן מדבר ישירות עם מסד הנתונים.

נקודה שמבלבלת רבים: בשירותים האלה יש מפתח ציבורי (ב-Supabase הוא נקרא anon או publishable) שאמור להיות בקוד הלקוח. זה תקין. ההגנה לא נשענת על הסתרת המפתח הזה אלא על חוקי הגישה: Row Level Security ב-Supabase ו-Security Rules ב-Firebase. אם החוקים לא מוגדרים, המפתח הציבורי פותח את כל המסד. לעומתו, מפתח ה-service_role של Supabase עוקף את כל החוקים, ואסור שיופיע בקוד לקוח בשום מצב.

מה מחפשים:

ב-Supabase: טבלאות ש-RLS כבוי בהן, או שמופעל בהן עם מדיניות בסגנון USING (true) שמתירה הכול.
ב-Firebase: חוקים כמו allow read, write: if true, או חוקים שבודקים רק שהמשתמש מחובר ולא שהמסמך שייך לו.
אחסון קבצים (Storage) ציבורי שמכיל מסמכים, תעודות או תמונות פרטיות.

הבדיקה שמוכיחה: נסו לקרוא טבלה מבחוץ עם המפתח הציבורי בלבד, בלי להתחבר.

curl "https://YOUR-PROJECT.supabase.co/rest/v1/profiles?select=*" \
  -H "apikey: YOUR_ANON_KEY" \
  -H "Authorization: Bearer YOUR_ANON_KEY"

קיבלתם רשימת משתמשים? המסד פתוח. קיבלתם מערך ריק או שגיאת הרשאה? הטבלה הזו מוגנת מפני קריאה אנונימית. חזרו על הבדיקה לכל טבלה שמכילה מידע אישי, ובדקו גם כתיבה ולא רק קריאה.

הפרומפט המתאים, אחרי שהדבקתם את סכמת המסד ואת חוקי הגישה (או נתתם לסוכן גישה לקובצי המיגרציה):

לפניך הסכמה וחוקי הגישה של מסד הנתונים שלי. פעל כבודק אבטחה שמנסה לגשת למידע שאינו שלו.

לכל טבלה בנה שורה בטבלת סיכום:
- אילו נתונים רגישים יש בה
- מה יכול לעשות משתמש לא מחובר (קריאה / הוספה / עדכון / מחיקה)
- מה יכול לעשות משתמש מחובר לרשומות של משתמש אחר
- האם החוק בודק בעלות על הרשומה או רק שהמשתמש מחובר

אחר כך:
1. סמן כל טבלה שאין עליה חוקים כלל.
2. מצא עמודות שמשתמש יכול לעדכן בעצמו ולא אמור (למשל role, is_admin, credits, plan).
3. כתוב לי את החוקים המתוקנים, ולכל אחד שאילתת בדיקה שאוכל להריץ כדי לוודא שהוא חוסם.

הסעיף השני חשוב במיוחד. חוק שמתיר למשתמש לעדכן את השורה שלו נשמע הגיוני, עד שמתברר שבאותה שורה יושבת גם העמודה is_admin.

שלב 3: דליפת פרטי משתמשים

גם כשהמפתחות מוסתרים והמסד נעול, מידע יכול לזלוג דרך הלוגיקה של האפליקציה עצמה. אלה המקומות הנפוצים:

גישה לפי מזהה. כתובת כמו /orders/1042 שמציגה את ההזמנה בלי לבדוק שהיא שייכת למשתמש המחובר. משנים את המספר ל-1043 ורואים הזמנה של מישהו אחר.
ה-API מחזיר יותר ממה שהמסך מציג. הדף מראה שם ותמונה, אבל התשובה מהשרת כוללת גם טלפון, מייל וכתובת. מה שלא מופיע על המסך עדיין מופיע בלשונית Network.
הודעות שגיאה מפורטות שחושפות מבנה טבלאות, נתיבי קבצים או שאילתות.
לוגים שרושמים סיסמאות, טוקנים או גוף בקשות מלא.
דפי ניהול שמוסתרים מהתפריט אבל פתוחים למי שמקליד את הכתובת.
הסתרה בצד הלקוח בלבד. כפתור שנעלם ממשתמש רגיל לא חוסם את הפעולה אם השרת לא בודק הרשאה בעצמו.

מבחן שני החשבונות הוא הבדיקה היעילה ביותר שתוכלו לעשות לבד. פתחו שני משתמשים, א’ ו-ב’, בשני דפדפנים. התחברו כמשתמש א’, צרו תוכן, והעתיקו את הכתובות ואת המזהים. עכשיו עברו למשתמש ב’ ונסו לפתוח את אותן כתובות, לערוך ולמחוק. כל פעולה שמצליחה היא דליפה. חזרו על כך גם בלי להתחבר בכלל.

אני רוצה שתמפה את כל נקודות הקצה (API routes / server actions / functions) בפרויקט.

לכל אחת ציין:
1. האם היא דורשת התחברות, ואיפה בדיוק בקוד זה נבדק.
2. האם היא בודקת שהמשאב המבוקש שייך למשתמש המחובר, או רק שהוא מחובר.
3. אילו שדות היא מחזירה, ואילו מהם רגישים ואינם נחוצים למסך שמשתמש בה.
4. האם קלט מהמשתמש נכנס לשאילתה, לנתיב קובץ או לפקודה בלי בדיקה.

סדר את הממצאים לפי חומרה. לכל ממצא חמור תאר בדיוק איך משתמש רגיל היה מנצל אותו, צעד אחר צעד, כדי שאוכל לשחזר בעצמי מול האפליקציה שלי.
אל תתקן כלום עדיין. קודם אני רוצה לראות את הרשימה המלאה.

ההוראה “אל תתקן כלום עדיין” מכוונת. כשהמודל מתחיל לתקן באמצע הסריקה הוא נוטה לעצור אחרי שניים־שלושה ממצאים ולהכריז שסיים.

שיטת העבודה: שני מודלים, סקירה צולבת

השיטה שמעלה את איכות הבדיקה היא לא לתת למודל שכתב את הקוד לבדוק את עצמו באותה שיחה. הוא מגיע עם כל ההנחות שהובילו לטעות מלכתחילה.

כך עושים את זה נכון:

שיחה חדשה ונקייה. פותחים שיחה בלי ההיסטוריה של הבנייה ומציגים את הקוד כקוד של מישהו אחר שצריך לבקר.
מודל אחד סוקר, השני מאתגר. מריצים את הסריקה ב-Claude, מעבירים את הדוח ל-ChatGPT עם הקוד הרלוונטי, ומבקשים ממנו להפריך. אחר כך הופכים את התפקידים. Gemini שימושי כקורא שלישי כשרוצים להזין כמות גדולה של קוד בבת אחת.
דורשים ראיות. כל ממצא צריך לכלול קובץ, שורה ודרך שחזור. ממצא בלי אלה הוא ניחוש.
מאמתים בעצמכם. דוח שאומר “הטבלה מוגנת” שווה פחות מפקודת curl שמחזירה שגיאת הרשאה.

פרומפט לסקירה הצולבת:

מצורף דוח אבטחה שכתב בודק אחר על הפרויקט שלי, יחד עם הקוד הרלוונטי.
אל תניח שהדוח נכון.

1. לכל ממצא: האם הוא אמיתי? הראה לי את השורות בקוד שמוכיחות או מפריכות אותו.
2. מה הדוח פספס? התמקד בהרשאות, בבעלות על רשומות, ובמידע שחוזר מהשרת.
3. האם אחד התיקונים המוצעים יוצר בעיה חדשה או שובר פונקציונליות?
4. דרג את רמת הביטחון שלך בכל קביעה: גבוהה, בינונית או נמוכה.

שלושה טיפים שפחות מדברים עליהם:

לעולם אל תדביקו מפתחות אמיתיים בצ’ט. החליפו אותם בטקסט כמו XXXX לפני ההדבקה. המודל צריך לראות איפה המפתח נמצא, לא מהו.
אחרי כל תיקון, הריצו שוב את הבדיקה הידנית. תיקון הרשאות נוטה לשבור משהו אחר, והמודל ידווח “תוקן” גם כשהחוק החדש חוסם את המשתמשים הלגיטימיים, או לא חוסם אף אחד.
שאלו “מה לא בדקת?”. התשובה לשאלה הזו היא לרוב החלק המועיל ביותר בדוח: הגדרות בלוח הבקרה של הענן, הרשאות של חשבונות צוות, שירותים חיצוניים שהמודל לא ראה.

אם האפליקציה שלכם כוללת סוכן AI שפועל בשם המשתמש, יש שכבת סיכון נוספת שמכוסה במדריך על ביקורת הרשאות לסוכנים והזרקת פרומפטים.

מתי חייבים מפתח אנושי

בדיקה עם מודלים תופסת את הכשלים הנפוצים והידועים. היא לא רואה את ההגדרות בחשבון הענן שלכם, לא מנסה לפרוץ בפועל, ולא נושאת באחריות. אלה המצבים שבהם לא עולים לאוויר בלי עין מקצועית:

כסף עובר דרך האפליקציה. סליקה, ארנקים, קרדיטים, מנויים. מספרי אשראי לא נוגעים בשרת שלכם בשום מצב, רק בדף של חברת הסליקה.
מידע רגיש. מידע רפואי, פיננסי, משפטי, תעודות זהות, או מידע על קטינים.
כתבתם מנגנון התחברות משלכם במקום להשתמש בשירות אימות מוכן. זה כולל שמירת סיסמאות, איפוס סיסמה וניהול סשנים.
כמה ארגונים חולקים מערכת אחת. במוצר B2B שבו לקוח אחד עלול לראות נתונים של לקוח אחר, טעות בודדת היא אירוע שמסיים עסקאות.
העלאת קבצים ממשתמשים, או כל מקום שבו קלט של משתמש מפעיל קוד, שאילתות או פקודות.
אתם עוברים מעשרות משתמשים לאלפים, או שלקוח ארגוני שולח לכם שאלון אבטחה.
שני המודלים חלוקים על ממצא חמור ואינכם יודעים להכריע.

יש גם היבט משפטי. מי שמחזיק מאגר עם מידע אישי בישראל כפוף לחוק הגנת הפרטיות ולתקנות אבטחת המידע, והחובות גדלות עם רגישות המידע והיקפו. אם אתם אוספים יותר משם ומייל, שווה שיחה עם עורך דין שמכיר את התחום. המדריך הזה אינו ייעוץ משפטי.

איך עושים את זה בלי להתרושש: לא חייבים לשכור מפתח במשרה. סקירת אבטחה ממוקדת של כמה שעות עם מפתח מנוסה או בודק חדירות מספיקה לרוב המוצרים הקטנים. כדי לנצל את הזמן הזה, הגיעו עם תרשים של זרימת המידע, רשימת השירותים החיצוניים, הדוחות שהפקתם מהמודלים, ורשימת מה שכבר תיקנתם. את המסמך הזה אפשר להכין עם המודל:

הכן מסמך הכנה לסקירת אבטחה אנושית של הפרויקט, באורך עמוד עד שניים.
כלול: ארכיטקטורה בקצרה, אילו נתונים אישיים נאספים ואיפה הם נשמרים, כל השירותים החיצוניים וסוג המפתח של כל אחד, איך עובדים האימות וההרשאות, מה נבדק כבר ומה תוקן, ומה נותר פתוח או לא ודאי.
כתוב עובדות בלבד. איפה שאינך בטוח, כתוב "לא אומת".

טעויות נפוצות

לשאול “זה מאובטח?” ולהסתפק ב“כן”. שאלה כללית מקבלת תשובה כללית. שאלו על טבלה מסוימת, נקודת קצה מסוימת, מפתח מסוים.
למחוק מפתח דלוף במקום לבטל אותו. המפתח ממשיך לעבוד, וההיסטוריה ב-Git זוכרת אותו.
להאמין ש“אף אחד לא מכיר את האתר שלי”. סורקים אוטומטיים מחפשים מפתחות ומסדים פתוחים ברצף, בלי קשר לגודל האתר.
לסמוך על הסתרה בממשק. כפתור מוסתר, דף שלא מקושר או בדיקה ב-JavaScript אינם הרשאה. רק בדיקה בשרת או במסד נחשבת.
להפעיל RLS ולעצור שם. הפעלה בלי מדיניות חוסמת הכול, ואז מוסיפים בלחץ מדיניות שמתירה הכול. בדקו מה כתוב במדיניות עצמה.
לבדוק רק עם החשבון שלכם. בעל האפליקציה רואה הכול ממילא. בלי משתמש שני ומשתמש לא מחובר לא בדקתם דבר.
להשאיר נתוני אמת בסביבת הבדיקות, או נתוני בדיקה וחשבון admin עם סיסמה פשוטה בסביבה החיה.
לתקן הכול בפרומפט אחד ענק. תקנו ממצא אחד, בדקו שהאפליקציה עדיין עובדת, ורק אז המשיכו לבא. כך תדעו גם איזה תיקון שבר מה.
לבדוק פעם אחת. כל פיצ’ר חדש שהמודל מוסיף יכול לפתוח טבלה חדשה בלי חוקים. חזרו על הבדיקה לפני כל שחרור משמעותי.

סיכום וצ’קליסט התחלה

בדיקת אבטחה לפני השקה היא שלוש שאלות קונקרטיות: האם סוד כלשהו מגיע לדפדפן, האם מישהו מבחוץ יכול לקרוא או לכתוב למסד, והאם משתמש אחד יכול לראות את המידע של אחר. המודלים טובים מאוד במיפוי ובאיתור, בתנאי שדורשים מהם ראיות ומאמתים בעצמכם. הם אינם תחליף לאדם מקצועי כשמדובר בכסף, במידע רגיש או בהיקף גדול.

צ’קליסט לפני העלייה לאוויר:

התחילו מהשלב הראשון עוד היום. חיפוש בלשונית Network לוקח חמש דקות, והוא הבדיקה שחושפת הכי הרבה ביחס לזמן שהיא דורשת.

→ לכל המדריכים

🧑‍💻 עוד מדריכים במפתחים ומתקדמים

→ לכל מדריכי מפתחים ומתקדמים