15 Security Tests: 15 מבחני אבטחה ואמינות לפני שמשיקים אפליקציית Vibe Coding

לפני שמתחילים

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

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

כללי בטיחות

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

מה המדריך הזה לא

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

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

איך עובדים עם הסוכן

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

פרומפט פתיחה להעתקה, לפני שעוברים מבחן אחרי מבחן:

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

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

15 המבחנים במבט אחד

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

מבחן 1: מי יכול לקרוא מידע של משתמש אחר

הדוגמה: משתמש ב מדביק בדפדפן שלו את הקישור הישיר למסמך הפרטי של משתמש א.

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

השם הטכני: Broken Access Control

השרת מזהה מי אתם, אבל לא בודק שהמסמך המבוקש שייך לכם. מוכר גם בשם IDOR.

מה עושים:

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

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

פרומפט להעתקה:

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

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

מקורות:

• OWASP Authorization
• Supabase Row Level Security

סמנו את התוצאה:

מבחן 2: האם משתמש רגיל יכול לבצע פעולת מנהל

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

מה קורה באפליקציה: כפתור מוסתר הוא עיצוב. בדיקת תפקיד בשרת היא בקרת גישה.

השם הטכני: Privilege Escalation

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

מה עושים:

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

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

פרומפט להעתקה:

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

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

מקורות:

• OWASP Authorization

סמנו את התוצאה:

מבחן 3: האם מפתח סודי נשלח לדפדפן

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

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

השם הטכני: Secret Exposure

מפתח שרת סודי שנכנס לקוד שהדפדפן מוריד. כל מי שפותח את האתר יכול לקרוא אותו.

מה עושים:

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

תוצאה צפויה: אין מפתחות שרת, סיסמאות או service role בצד הלקוח. מפתח ציבורי אינו מחליף כללי הרשאה.

פרומפט להעתקה:

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

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

מקורות:

• Supabase Securing your data
• GitHub Secret scanning

סמנו את התוצאה:

מבחן 4: מה קורה אחרי ניסיונות כניסה שגויים

הדוגמה: מישהו מנסה סיסמה אחרי סיסמה על אותו חשבון.

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

השם הטכני: Rate Limiting

הגבלת קצב: אחרי מספר ניסיונות שגויים השרת מאט או חוסם זמנית.

מה עושים:

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

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

פרומפט להעתקה:

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

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

מקורות:

• OWASP Authentication

סמנו את התוצאה:

מבחן 5: אילו קבצים מותר להעלות

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

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

השם הטכני: File Upload Validation

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

מה עושים:

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

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

פרומפט להעתקה:

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

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

מקורות:

• OWASP File Upload

סמנו את התוצאה:

מבחן 6: האם מידע פרטי נגיש בלי להתחבר

הדוגמה: מישהו מקבל קישור לדוח פרטי ופותח אותו בחלון פרטי, בלי להתחבר.

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

השם הטכני: Missing Authentication

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

מה עושים:

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

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

פרומפט להעתקה:

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

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

מקורות:

• OWASP Authorization
• OWASP Authentication

סמנו את התוצאה:

מבחן 7: האם קישור לאיפוס סיסמה עובד שוב

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

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

השם הטכני: Password Reset Token

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

מה עושים:

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

תוצאה צפויה: קישור שכבר נוצל או פג תוקפו אינו מאפשר איפוס נוסף. אין לשמור את הקישור ביומן ציבורי.

פרומפט להעתקה:

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

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

מקורות:

• OWASP Forgot Password

סמנו את התוצאה:

מבחן 8: האם אפשר לעקוף את ההרשאות דרך מסד הנתונים

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

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

השם הטכני: Row Level Security

כללים בתוך מסד הנתונים שקובעים איזו שורה כל משתמש רשאי לקרוא או לשנות. בקיצור RLS.

מה עושים:

• אם אתם משתמשים ב-Supabase עם גישה מהלקוח, בדקו גישה לטבלה חשופה כמשתמש א, כמשתמש ב וללא התחברות.
• אל תבצעו את הבדיקה עם מפתח שרת שעוקף הרשאות.

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

פרומפט להעתקה:

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

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

מקורות:

• Supabase Row Level Security
• Supabase Securing your data

סמנו את התוצאה:

מבחן 9: האם קובץ פרטי באמת נשאר פרטי

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

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

השם הטכני: Storage Access Control

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

מה עושים:

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

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

פרומפט להעתקה:

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

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

מקורות:

• Supabase Storage Access Control

סמנו את התוצאה:

מבחן 10: האם עריכת פרופיל יכולה להפוך משתמש למנהל

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

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

השם הטכני: Mass Assignment

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

מה עושים:

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

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

פרומפט להעתקה:

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

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

מקורות:

• OWASP Mass Assignment

סמנו את התוצאה:

מבחן 11: מי קובע את המחיר בקופה

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

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

השם הטכני: Price Tampering

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

מה עושים:

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

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

פרומפט להעתקה:

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

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

מקורות:

• Stripe, determining the amount on the server

סמנו את התוצאה:

מבחן 12: האם ניסיון חוזר יוצר שתי הזמנות

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

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

השם הטכני: Idempotency

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

מה עושים:

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

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

פרומפט להעתקה:

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

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

מקורות:

• Stripe Idempotent requests

סמנו את התוצאה:

מבחן 13: האם אפשר לשלוח ערך שהטופס לא מאפשר

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

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

השם הטכני: Server-Side Input Validation

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

מה עושים:

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

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

פרומפט להעתקה:

כתוב בדיקות שרת לכמות שלילית, שדה חסר ואורך חריג. ודא שאין כתיבה למסד כאשר הקלט לא תקין.

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

מקורות:

• OWASP Input Validation

סמנו את התוצאה:

מבחן 14: מה נחשף בהודעות שגיאה וביומנים

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

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

השם הטכני: Secure Logging

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

מה עושים:

• גרמו לשגיאת דמה מבוקרת.
• בדקו את התשובה למשתמש ואת יומני השרת.
• השתמשו בסימני דמה במקום סודות אמיתיים.

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

פרומפט להעתקה:

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

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

מקורות:

• OWASP Logging

סמנו את התוצאה:

מבחן 15: האם אפשר לשחזר מידע שנמחק

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

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

השם הטכני: Backup Restore Test

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

מה עושים:

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

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

פרומפט להעתקה:

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

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

מקורות:

• Supabase Database Backups
• AWS, testing recovery from backups

סמנו את התוצאה:

מגבלות

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

מקורות

• כל המבחנים מבוססים על התיעוד הרשמי הזה:
• OWASP Authorization
• Supabase Row Level Security
• Supabase Securing your data
• GitHub Secret scanning
• OWASP Authentication
• OWASP File Upload
• OWASP Forgot Password
• Supabase Storage Access Control
• OWASP Mass Assignment
• Stripe, determining the amount on the server
• Stripe Idempotent requests
• OWASP Input Validation
• OWASP Logging
• Supabase Database Backups
• AWS, testing recovery from backups