אבטחת Vibe Coding: איך להגן על אפליקציה שנבנתה בעזרת AI

תוכלו למצוא הוראות נוספות לעבודה עם Ailoot בתיעוד.

למה פורצים לאפליקציות שנבנו בעזרת AI לעיתים קרובות יותר?#

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

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

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

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

מה כבר למדו יוצרי vibe coding בדרך הקשה?#

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

Lovable ו-RLS כבוי. פלטפורמת Lovable בונה אפליקציות מתיאורים טקסטואליים. ב-2025 נמצאה פגיעות מערכתית באפליקציות שלה והיא קיבלה את המספר CVE-2025-48757. הסיבה: באפליקציות שנוצרו לא היו כללי גישה למסד הנתונים ברמת השורה (RLS, שיוסבר בהמשך). חוקר בדק מדגם ומצא 303 נקודות גישה חשופות ב-170 אפליקציות. שמות, מספרי טלפון, סטטוסי תשלום, מפתחות API של אנשים אחרים ואפילו כתובות מגורים נחשפו. בכ-70 אחוזים מהאפליקציות שנבדקו, ההגנה ברמת השורה הייתה כבויה לחלוטין.

Tea ונתונים רגישים. אפליקציית Tea (ביקורות אנונימיות על אנשים) איבדה בערך 72,000 תמונות ביולי 2025, ובהן 13,000 תמונות סלפי ותמונות של מסמכים, ואחר כך יותר ממיליון הודעות פרטיות. הסיבה הטכנית הייתה אחסון פתוח ובדיקות גישה חלשות. קהילת האבטחה מציגה את Tea כדוגמה בולטת: כשחשובה יותר השקה מהירה מבדיקת הרשאות, נתונים רגישים הם הראשונים לדלוף.

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

שתי חזיתות לאבטחה: היכן בדיוק אתם חשופים?#

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

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

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

Anthropic, החברה שמאחורי Claude, מציגה כך את עקרון ההגנה המרכזי — והוא מתאים לשתי החזיתות:

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

רוצים שה-AI יעבוד באופן צפוי ויפסיק לירות לכם ברגל בכל פרויקט חדש? כללי אבטחה הם חלק מהמוח השני שלכם: כתבו אותם פעם אחת ב-CLAUDE.md, והסוכן יפעל לפיהם בכל בקשה.

מה סוכן AI יכול לעשות כשהוא מקבל גישה למחשב שלכם?#

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

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

מה אפשר לעשות בפועל, גם אם אינכם מתכנתים?

1. אל תפעילו את הסוכן במצב "לאפשר הכול" במכונת ייצור

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

2. אסרו על הסוכן לקרוא סודות

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

3. שמרו את מפתחות הייצור בנפרד

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

4. השתמשו בארגז החול של הכלי

   כלי AI מודרניים יכולים להריץ פקודות בבידוד (ארגז חול), ללא גישה לשאר המערכת. ב-Claude Code הדבר מצמצם בקשות הרשאה בכ-84 אחוזים — כך שהוא גם נוח יותר.

כלל שחוסם קריאת סודות ב-Claude Code נראה בערך כך — הוסיפו אותו להגדרות ההרשאות:

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(**/.env)",
      "Bash(git push *)"
    ]
  }
}

היכן אסור להכניס מפתחות API וסיסמאות?#

הטעות הזולה והנפוצה ביותר היא הכנסת מפתחות לקוד. מפתח API לשירות תשלומים, סיסמת מסד נתונים, אסימון של בוט — כל אלה סודות. מקומם בקובץ .env נפרד, והקובץ הזה חייב להופיע ב-.gitignore כדי שלא יעלה ל-git יחד עם הקוד.

היקף הבעיה ב-2025: 28.65 מיליון סודות חדשים שהוטמעו בקוד במאגרים ציבוריים, עלייה של 34 אחוזים לעומת השנה הקודמת. דליפות של מפתחות לשירותי AI עלו ב-81 אחוזים. Vibe coding מוסיף שמן למדורה, מפני שהסוכן מבצע commit בלי לבדוק.

מה לבדוק ידנית עכשיו:

1. פתחו את קובץ .gitignore של הפרויקט

   ודאו שיש בו שורה עם .env. אם אין, הוסיפו אותה לפני ה-commit הראשון.

2. היכנסו למאגר שלכם ב-GitHub

   בדקו שקובץ .env אינו נמצא שם. חיפוש במאגר אחר .env או אחר חלק מהמפתח שלכם הוא דרך מהירה לבדוק.

3. אם מפתח דלף, בטלו אותו והנפיקו חדש

   מחיקת ה-commit אינה מספיקה: ייתכן שכבר לקחו את המפתח. היכנסו לשירות (ספק התשלומים, שירות הענן, ספק ה-AI), בטלו את המפתח הישן והנפיקו מפתח חדש. לזה קוראים רוטציה.

4. תנו למפתחות את ההרשאות המינימליות

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

למה כולם יכולים לראות את מסד הנתונים בלי RLS?#

אם אתם בונים אפליקציה ב-Supabase או במסד נתונים דומה, זהו החלק החשוב ביותר. RLS הוא קיצור של Row Level Security, אבטחה ברמת השורה. בפשטות, זהו כלל שקובע אילו שורות בטבלה יוצגו למשתמש מסוים. בלעדיו, טבלת "orders" מחזירה לכולם את ההזמנות של כל הלקוחות.

כך אומר זאת במפורש התיעוד של Supabase:

וכאן המלכודת העיקרית ליוצרי vibe coding. כשיוצרים טבלה באמצעות לחיצה בלוח הבקרה של Supabase, ההגנה מופעלת אוטומטית. אבל כשה-AI יוצר את הטבלה — והוא כמעט תמיד כותב פקודות SQL ישירות — RLS נשאר כבוי כברירת מחדל. המשמעות היא שכמעט בוודאות טבלה שיצר סוכן פתוחה לכל האינטרנט. בדיוק כך דלפו הנתונים מ-170 אפליקציות Lovable.

מה לעשות:

1. שאלו את הסוכן ישירות

   כתבו: “הציגו לי את כל הטבלאות שבהן RLS כבוי.” ה-AI יציג רשימה — זהו תור העבודה שלכם.

2. הפעילו RLS בכל טבלה עם נתוני משתמשים

   והוסיפו לפחות מדיניות גישה אחת — למשל, “משתמש יכול לראות רק את השורות שלו”.

3. בדקו את לוח הבקרה

   בלוח הבקרה של Supabase, בכל טבלה אמור להופיע “RLS enabled”. אם הסימון אפור או אדום, פירוש הדבר שהטבלה פתוחה.

4. בדקו זאת בפועל

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

למה בדיקות הרשאה בממשק לא מגינות עליכם?#

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

דוגמה קלאסית נקראת IDOR. דמיינו שאתם פותחים את ההזמנה שלכם בכתובת עם id=123. שנו אותה ל-id=124, ותוכלו לראות את ההזמנה של מישהו אחר מפני שהשרת לא בדק אם זו באמת ההזמנה שלכם. זו אחת הפרצות הנפוצות ביותר באפליקציות שנבנו ב-vibe coding, ובדיקות הרשאה חלשות היו הגורם לדליפה של Tea.

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

איך אפשר לבדוק בקוד פרצות אם אינכם מתכנתים?#

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

1. הפקודה /security-review ב-Claude Code. בדיקה חד-פעמית של הענף הנוכחי לאיתור הזרקת SQL, XSS, פרצות הרשאה, דליפות נתונים ובעיות בתלויות. במדריך נפרד הסברתי שלב אחר שלב איך היא עובדת ואיך לצרף בדיקה אוטומטית לכל שינוי: סקירת אבטחה ב-Claude Code. העיקר כאן: זהו קו ההגנה הראשון, ומפעילים אותו בפקודה אחת.

2. תוסף security-guidance הרשמי. התקינו אותו מחנות התוספים הרשמית באמצעות /plugin install security-guidance@claude-plugins-official (נדרשת גרסת Claude Code 2.1.144 ואילך). הוא בודק קוד בשלושה שלבים: בכל עריכה, בסוף כל תור ובזמן commit. הוא מאתר עקיפות הרשאה, IDOR, הזרקות והצפנה חלשה. אבל Anthropic מבהירה את מגבלותיו:

npx skills add <author>/<repo>

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

לשם הקשר: גם הגופים הגדולים החלו להתייחס ברצינות לאבטחת קוד שנוצר ב-AI. במסגרת Project Glasswing, שהתרחב ב-2 ביוני 2026 וכלל 150 ארגונים, השותפים מצאו בתוך זמן קצר יותר מ-10,000 פגיעויות קריטיות באמצעות מודלים של Anthropic. ההשלכות ברורות:

האם אפשר לסמוך על מיומנויות ותוספים מ-GitHub?#

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

ניקח את אוסף המיומנויות מהסעיף הקודם. השם שלו כולל את “Anthropic”, מה שגורם לכם להוריד את המגננות. אבל התיאור שלו עצמו אומר בבירור:

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

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

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

מה יציל אתכם אחרי פריצה: גיבויים וחזרה לאחור#

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

מכאן נובעים שני כללים.

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

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

רשימת בדיקה לאבטחה לפני פרסום#

עברו על הרשימה הזאת ממש לפני הפרסום. לפי הסדר.

1. סודות ב-.env, וקובץ .env בתוך .gitignore. אין מפתחות בקוד. קובץ .env לא נמצא במאגר ציבורי.

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

3. RLS מופעל בכל הטבלאות שמכילות נתוני משתמשים, ומדיניות הגישה מוגדרת.

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

5. אימות חתימת webhook. כל מטפל בהתראות חיצוניות (תשלומים, טפסים) מאמת את החתימה.

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

7. הסוכן אינו פועל במצב "לאפשר הכול" במכונה עם מפתחות ייצור. הגישה לקריאת .env חסומה.

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

9. הקוד נבדק באמצעות /security-review או תוסף security-guidance. הממצאים תוקנו.

10. המיומנויות וההרחבות של אחרים נבדקו לפני ההתקנה. שום דבר לא הותקן "בעיניים עצומות".

מאיפה להתחיל היום#

אל תנסו ליישם ערב אחד את כל מה שמופיע במדריך — בסוף לא תעשו דבר. בצעו היום את שלושת הצעדים החשובים ביותר:

1. בדקו את הסודות שלכם. פתחו את .gitignore, ודאו ש-.env מופיע בו, ובדקו שאין מפתחות במאגר הציבורי. אם מפתחות דלפו, בטלו אותם והנפיקו חדשים.
2. שאלו על RLS. אמרו לסוכן: “הציגו לי את הטבלאות שבהן RLS כבוי” — והפעילו אותו בכל מקום שבו מאוחסנים נתונים של אנשים.
3. הגדירו גיבויים תכופים. כך שאם משהו ישתבש, תאבדו דקות ולא ימים.

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

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

להמשך העבודה עם מודלים, תוכלו לעבור אל Ailoot.