אבטחה ב-Vibe Coding: 27 בדיקות לפני שמעלים אפליקציה לאוויר

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

שמרתי השבוע ריל של BreakingBreach, ואמרתי לעצמי שזו רשימה שכל מי שבונה ב-Vibe Coding צריך להכיר. כל הריל הוא פרומפט אחד ל-Claude: "אני לא רוצה שהאקרים ייכנסו לאפליקציה שבניתי", ואחריו 27 בקשות קצרות, אחת כל שנייה וחצי.

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

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

מה בדיוק יש בפרומפט?

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

זה הפרומפט המקורי מהריל, כמו שהוא. אפשר להדביק אותו ב-Claude Code מתוך התיקייה של הפרויקט:

Claude, I don't want hackers getting into my vibe-coded app, so please set up proper authentication, hide API keys, secure my database, enforce HTTPS, hash passwords, validate my forms server side, protect against XSS, log and monitor suspicious activity, lock down my admin routes, use parameterized queries, check my environment variables, add rate limiting, restrict my CORS settings, add security headers, secure my session cookies, add CSRF protection, make password reset links expire, restrict file upload types and sizes, verify prices and payments, disable production debug mode, update vulnerable dependencies, remove unused packages, check for exposed files, scan my git history for leaked secrets, revoke and replace compromised keys, run a thorough security review. And finally, test the protections and give me a report of findings and fixes.

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

27 הבדיקות, ב-6 קבוצות

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

כניסה, סיסמאות והרשאות (5)

• מערכת כניסה נכונה: מי שלא מחובר לא רואה כלום, גם אם הוא מקליד כתובת ישירה של דף "נסתר".
• גיבוב סיסמאות: הסיסמה נשמרת במסד רק אחרי גיבוב (hash), אף פעם כטקסט רגיל. בריל מוצג Argon2id, אלגוריתם שנבנה בדיוק לזה.
• נעילת דפי הניהול: הבדיקה אם מישהו הוא מנהל נעשית בשרת. להסתיר כפתור במסך זה לא הגנה.
• עוגיות התחברות מאובטחות: העוגייה שמחזיקה את ההתחברות נשלחת רק בחיבור מוצפן, וקוד שרץ בדף לא יכול לקרוא אותה.
• קישורי איפוס שפגים: קישור לאיפוס סיסמה עובד פעם אחת ולזמן קצר.

מפתחות וסודות (4)

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

מסד הנתונים והקלט מהמשתמש (7)

• אבטחת מסד הנתונים: בלי גישה ציבורית, הרשאות מינימליות, וחוקי גישה לכל טבלה. משתמש רואה רק את ההזמנות שלו.
• שאילתות עם פרמטרים: מה שהמשתמש מקליד לא מודבק ישירות לשאילתה. ככה נמנעת הזרקת SQL.
• בדיקת טפסים בשרת: כל טופס נבדק שוב בשרת. את הבדיקה בדפדפן עוקפים בקלות, ופתאום מישהו מזמין "מינוס 3" יחידות.
• הגנה מ-XSS: טקסט שמשתמש כתב, למשל בתגובה, מוצג כטקסט ולא רץ כקוד אצל משתמש אחר.
• הגנת CSRF: אתר זר לא יכול לשלוח פעולה בשם משתמש שמחובר אצלכם.
• הגבלת העלאת קבצים: רק סוגים מותרים ועד גודל מסוים. קובץ הרצה שמתחפש לחשבונית נדחה.
• אימות מחירים ותשלומים: המחיר נקבע בשרת. אם הדפדפן שולח "1 דולר" על מוצר של 49, השרת מזהה ועוצר.

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

השרת והתעבורה (6)

• HTTPS בלבד: כל התעבורה מוצפנת, וכתובת בלי הצפנה מעבירה לבד לגרסה המוצפנת.
• הגבלת קצב: מי ששולח מאות ניסיונות כניסה בדקה נחסם לזמן מה.
• הגבלת CORS: רק האתרים שלכם יכולים לפנות לשרת מתוך הדפדפן.
• כותרות אבטחה: הוראות שהשרת שולח לדפדפן ומגינות על הדף, כמו CSP ו-HSTS.
• כיבוי מצב דיבאג: באתר החי אין הודעות שגיאה מפורטות שחושפות קוד ונתיבים.
• בדיקת קבצים חשופים: אי אפשר להוריד מהאתר קבצים כמו ‎.env, גיבוי של המסד או את תיקיית הגיט.

ספריות ותלויות (2)

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

ניטור ובדיקה סופית (3)

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

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

איפה פרומפט אחד לא מספיק?

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

"תוקן" זה לא הוכחה

כשמבקשים מ-Claude 27 דברים בבת אחת, הוא יחזיר רשימה מסודרת עם הרבה סימני וי. חלק מהם יהיו אמיתיים, וחלק יהיו "הוספתי" בלי שאף אחד בדק שזה עובד. תבקשו לכל תיקון הוכחה: איזה קובץ השתנה, ואיך בודקים אותו.

חלק מהבדיקות הן לא קוד

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

הוא בודק את מה שהוא עצמו כתב

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

שינויים גדולים בבת אחת שוברים דברים

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

מה אני הייתי עושה

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

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

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

שאלות נפוצות

אפשר לסמוך על Claude שיאבטח לבד את האפליקציה?

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

האם צריך את כל 27 הבדיקות גם לאפליקציה קטנה?

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

מה הכי דחוף מתוך הרשימה?

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

זה מחליף בדיקת אבטחה מקצועית?

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

צריכים שמישהו יבנה לכם סוכן AI או מערכת ברמת אבטחה של חברה? ב-Agentic-dev, החברה שלי, אנחנו מפתחים סוכני AI ואוטומציות לחברות: לאתר של Agentic-dev. רוצים שהצוות שלכם ידע לבנות עם Claude Code בעצמו, ובצורה בטוחה? לסדנאות.

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

מקור: רשימת הבדיקות והפרומפט מתוך הריל של BreakingBreach באינסטגרם. ההסברים בעברית והחלוקה לקבוצות הם שלי. רקע נוסף: OWASP Top 10 · הסברים על סוגי התקפות ב-OWASP · Argon2.