כשהדלת פתוחה לרווחה: מה זה Missing Authentication ולמה זה קריטי

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

כך בדיוק נראית פגיעות Missing Authentication (אימות חסר) בעולם התוכנה.

מה זה אימות?

אימות (Authentication) הוא התהליך שבו מערכת שואלת: “מי אתה?” — לפני שהיא מאשרת גישה. שם משתמש וסיסמה הם הדוגמה הקלאסית, אבל יש גם טוקנים, מפתחות API, ותעודות דיגיטליות.

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

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

מה קורה כשהאימות חסר?

כאשר endpoint (נקודת קצה, כלומר כתובת URL שמקבלת בקשות) אינו מחייב אימות, כל אחד שמוצא אותה — או שמנחש את הכתובת — יכול להשתמש בה. בלי שם משתמש. בלי סיסמה. בלי שום הרשאה.

מה שהתוקף יכול לעשות שם תלוי רק בפעולות שה-endpoint חושף:

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

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

הדוגמה האמיתית: Langflow ו-CVE-2026-33017

בתחילת 2026, התגלתה פגיעות קריטית ב-Langflow — פלטפורמת קוד-פתוח לבניית תזרימי עבודה עם בינה מלאכותית.

הרעיון מאחורי החולשה היה פשוט: endpoint שאחראי על עיבוד Flows (תזרימי עבודה) היה חשוף לציבור — ולא דרש שום אימות. מי שידע את הכתובת יכול היה לשלוח אליה בקשה, ובה פקודות שהפלטפורמה תריץ ישירות.

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

זו לא פגיעות בלוגיקה מורכבת או חולשה בהצפנה — זו שכחה פשוטה: מישהו לא שאל “האם המשתמש הזה אמור להיות כאן?”

זה לא תאונה נדירה — זה OWASP מספר 1

ארגון OWASP (Open Web Application Security Project) מפרסם בקביעות את רשימת הפגיעויות הנפוצות ביותר ביישומי ווב. בגרסת 2021, Broken Access Control — שכוללת גם Authentication חסר וגם הרשאות שגויות — עלתה למקום הראשון ברשימה.

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

• לחץ זמן בפיתוח: “נוסיף את האימות אחרי השקה.” זה לא קורה.
• הנחות שגויות: “ה-endpoint הזה פנימי, אף אחד לא יגיע אליו.” עם API חשוף לאינטרנט, אין דבר כזה “פנימי” באמת.
• endpoints שנשכחים: פיצ’ר ישן שנשאר פעיל, route שלא הוסר, גרסת debug שנשארה בפרודקשן.
• ריבוי צוותים: Frontend כתב את הקריאה, Backend כתב את ה-endpoint — אף אחד לא בדק מי מטפל בהרשאות.

איך מתגוננים?

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

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

בדיקות אוטומטיות — 401 בלי טוקן = כשל. כחלק מחבילת הבדיקות, הוסיפו בדיקה שמנסה לגשת לכל endpoint מוגן — בלי שום אימות. אם השרת מחזיר 200 OK במקום 401 Unauthorized או 403 Forbidden — הבדיקה נכשלת, ויש בעיה.

עיקרון המינימום (Least Privilege). גם אחרי שאימות קיים, שאלו: מה הצד השני באמת צריך? משתמש רגיל לא צריך גישה לנתוני ניהול. שירות חיצוני לא צריך יכולת מחיקה. מגבילים כל גורם לגישה המינימלית שהוא באמת צריך — לא יותר.

סיכום

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

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