כשהדלת פתוחה לרווחה: מה זה 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, ובדיקות קוד אוטומטיות עוזרים לבנות את המפה הזו.

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

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

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

סיכום

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

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