בדיקות אבטחה ל-API: SAST, DAST ובדיקות הרשאה שתופסות IDOR לפני פרודקשן

מאת צוות מדיה דיל · 07.08.2026 · API Engineering · 8 דק׳

endpoint שבודק התחברות אבל לא בעלות על משאב הוא פער אבטחה קלאסי (IDOR). מדריך לבניית מסגרת בדיקות אבטחה שתופסת חולשות כאלה לפני שהן מגיעות ללקוחות.

שבוע לפני עלייה לאוויר, סקירת קוד שגרתית מגלה ש-endpoint שמחזיר פרטי הזמנה בודקת רק שהמשתמש מחובר, אבל לא שההזמנה שייכת לו - כל משתמש מחובר יכול לבקש /api/orders/1, /api/orders/2 וכן הלאה, ולקבל פרטי הזמנות של לקוחות אחרים לגמרי, כולל כתובות וסכומי תשלום. זו לא חולשה אקזוטית - זו IDOR (Insecure Direct Object Reference), אחת מחולשות ה-API הנפוצות ביותר, וסביר שהיא הייתה עוברת בלתי מזוהה עד לפרודקשן אם צוות הבדיקות היה מסתפק בבדיקות פונקציונליות רגילות בלבד. בדיקות אבטחה ל-API הן לא שלב אופציונלי שמתווסף "אם יישאר זמן" - הן חלק מובנה מתהליך הפיתוח שמונע בדיוק את סוג הפער הזה מלהגיע ללקוחות אמיתיים.

OWASP API Security Top 10 - המסגרת שממקדת את המאמץ

במקום לנחש אילו חולשות לחפש, OWASP מפרסמת רשימה מעודכנת של עשר קטגוריות החולשות הנפוצות ביותר ספציפית ב-API-ים (לא זהה לרשימת ה-Top 10 הכללית לאפליקציות ווב). הרשימה כוללת בין היתר Broken Object Level Authorization (בדיוק החולשה מתרחיש הפתיחה - IDOR), Broken Authentication, Excessive Data Exposure (החזרת יותר שדות מהנדרש בתשובת API), Lack of Resources & Rate Limiting, Broken Function Level Authorization, ו-Security Misconfiguration. שימוש ברשימה הזו כרשימת מחסום לפני כל שחרור גרסה נותן כיסוי בסיסי שיטתי, במקום להסתמך על זיכרון או ניחוש אישי של כל מפתח לגבי מה כדאי לבדוק.

SAST - סריקת קוד סטטית שרצה לפני שהקוד בכלל רץ

Static Application Security Testing (SAST) סורק את קוד המקור עצמו, בלי להריץ אותו, ומחפש דפוסים מסוכנים ידועים - שאילתות SQL שמורכבות מהדבקת מחרוזות (פוטנציאל להזרקה), שימוש בפונקציות הצפנה חלשות או מיושנות, סודות (מפתחות API) שנשמרו בטעות בקוד עצמו. היתרון המרכזי של SAST הוא מהירות המשוב - הוא יכול לרוץ כחלק מה-CI על כל Pull Request, ולתפוס בעיה תוך דקות, הרבה לפני שהקוד מגיע לסביבת בדיקה כלשהי או נבדק על ידי אדם. החיסרון הוא שיעור False Positive גבוה יחסית - SAST לא "מבין" הקשר עסקי, ולכן מדגיש הרבה דפוסים שנראים מסוכנים אך בפועל בטוחים, מה שדורש כיוונון (Tuning) של הכלים כדי שהם לא יהפכו לרעש שהצוות מתעלם ממנו. חשוב גם לתעדף את הממצאים לפי חומרה אמיתית ולא לטפל בכולם באותה דחיפות - כלי SAST טוב מדרג ממצאים לפי רמת ביטחון וחומרה, ומאפשר להתמקד תחילה בבעיות קריטיות ובטוחות (High Confidence, High Severity) לפני שמבזבזים זמן על ממצאים שוליים.

DAST - תקיפה של API רץ מבחוץ

Dynamic Application Security Testing (DAST) פועל אחרת לגמרי - הוא שולח בקשות אמיתיות ל-API רץ (בסביבת בדיקה, לא פרודקשן) ומנסה תבניות תקיפה ידועות - הזרקת SQL, XSS, מניפולציה של פרמטרים, ניסיון גישה למשאבים בלי הרשאה מתאימה. היתרון הוא שהוא בודק את המערכת האמיתית כפי שהיא מתנהגת בפועל, כולל אינטראקציות בין רכיבים שקוד סטטי לא יכול לחזות. החיסרון הוא שהוא דורש סביבה רצה מלאה, ולכן רץ מאוחר יותר בתהליך הפיתוח מ-SAST - בדרך כלל כחלק מ-Pipeline של בדיקות לפני שחרור, לא על כל Commit בודד.

בדיקות הרשאה - הכלי הייעודי ל-BOLA/IDOR

חולשות מסוג Broken Object Level Authorization, כמו זו שנחשפה בתרחיש הפתיחה, לא נתפסות היטב על ידי SAST או DAST גנריים - הן דורשות הבנה עסקית של "מי אמור לגשת למה". הבדיקה הייעודית והיעילה ביותר היא בדיקת הרשאה שיטתית: עבור כל endpoint שמקבל מזהה משאב (/orders/{id}, /users/{id}), ליצור שני משתמשי בדיקה, לבצע פעולה עם המשתמש הראשון, ואז לנסות לגשת לאותו משאב עם המשתמש השני - הבדיקה אמורה להיכשל עם 403 או 404, לא להצליח. זו בדיקה שאפשר וכדאי לאוטומט לחלוטין ולהריץ כחלק מסוויטת הבדיקות הרגילה, לא רק כבדיקה ידנית מזדמנת. חשוב גם לכסות לא רק קריאות GET אלא כל פעולת שינוי (PUT, PATCH, DELETE) על משאב - לעיתים דווקא פעולות עריכה או מחיקה נשארות פרוצות גם כשקריאת המידע עצמה כבר מוגנת כראוי, כי מפתחים נוטים לבדוק הרשאות בקפידה רבה יותר בנתיבי הקריאה מאשר בנתיבי הכתיבה.

test('IDOR: לא ניתן לגשת להזמנה של משתמש אחר', async () => {
  const order = await createOrderAs(userA);
  const res = await request(app)
    .get(`/api/orders/${order.id}`)
    .set('Authorization', `Bearer ${tokenOf(userB)}`);
  expect(res.status).toBe(403);
});

ולידציית קלט - הבדיקה הבסיסית שקל להזניח

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

בדיקות בשכבת ה-CI/CD - מתי כל בדיקה רצה

שילוב נכון בין סוגי הבדיקות השונים לתהליך הפיתוח קובע כמה מהר בעיה נתפסת ובאיזה עלות. SAST, מהיר יחסית, יכול לרוץ על כל Pull Request. בדיקות הרשאה אוטומטיות, כחלק מסוויטת בדיקות רגילה, רצות על כל דיפלוי לסביבת בדיקה. DAST, שאיטי יותר ודורש סביבה מלאה, רץ לרוב פעם ביום או לפני כל שחרור לפרודקשן. סריקת תלויות (Dependency Scanning) לחולשות ידועות בספריות צד שלישי רצה גם היא באופן קבוע, כי חולשות חדשות מתגלות כל הזמן גם בקוד שלא השתנה. מבנה מדורג כזה - בדיקות מהירות ותכופות ליד הקוד, בדיקות איטיות ומקיפות יותר לפני שחרור - נותן איזון בין מהירות פיתוח לביטחון סביר.

Excessive Data Exposure - כשהתשובה חושפת יותר ממה שהוצג

חולשה נפוצה ומפתיעה בהיקפה היא החזרת שדות נוספים בתשובת ה-API שהלקוח לא באמת אמור לראות, גם אם ה-UI עצמו לא מציג אותם. מקרה קלאסי: endpoint שמחזיר אובייקט משתמש שלם ישירות ממסד הנתונים, כולל שדה password_hash או פרטי כרטיס אשראי חלקיים, מתוך הנחה ש"הפרונטאנד ממילא לא מציג את זה". הבעיה היא שכל מי שבודק את תעבורת הרשת (למשל עם כלי כמו DevTools) רואה את השדה המלא, גם אם הוא לא מוצג בממשק. הבדיקה הנכונה היא לא לבדוק רק מה מוצג במסך, אלא לבדוק ישירות את תוכן תשובת ה-API הגולמית ולוודא שהיא כוללת אך ורק שדות שאושרו במפורש לחשיפה - עיקרון שמכונה Response Whitelisting, בדומה לרעיון ה-Whitelist שנדון בהקשר של שכבת סינון.

בדיקת קונפיגורציה ותשתית - לא רק קוד

חלק ניכר מהחולשות בפועל לא נובע מבאג בלוגיקה העסקית אלא מקונפיגורציה שגויה - כותרות CORS פתוחות מדי שמאפשרות לכל דומיין לקרוא ל-API, כותרות אבטחה חסרות (כמו Strict-Transport-Security או X-Content-Type-Options), או ממשקי ניהול פנימיים (כמו לוח בקרה של מסד נתונים) שנשארו נגישים בטעות מהאינטרנט הפתוח. בדיקת קונפיגורציה שיטתית - לא רק בדיקת קוד - צריכה להיות חלק קבוע מהתהליך, כי טעויות מהסוג הזה נוטות להישמט מכל כלי בדיקה שממוקד רק בקוד האפליקציה עצמו. כלים ייעודיים לסריקת קונפיגורציית תשתית (Infrastructure as Code Scanning) יכולים לתפוס חלק ניכר מהבעיות האלה עוד לפני הפריסה בפועל, אם ה-Infrastructure מוגדר כקוד (Terraform, CloudFormation) ולא משתנה ידנית מחוץ לתהליך המבוקר.

Trade-offs - כיסוי מקיף מול מהירות פיתוח

בדיקות אבטחה מקיפות לוקחות זמן - זמן ריצה בפועל, וזמן תיקון של False Positives שהכלים מזהים. הפיתוי הוא לוותר עליהן כדי להאיץ שחרור, אבל זו פשרה מסוכנת - עלות תיקון חולשת אבטחה שהתגלתה בפרודקשן (ולעיתים אחרי שכבר נוצלה בפועל) גבוהה לאין שיעור מעלות זיהוי ותיקון שלה בשלב הפיתוח. הפתרון המעשי הוא לא "לוותר או לעשות הכל", אלא לדרג עדיפויות - endpoints רגישים במיוחד (טיפול בכסף, מידע אישי, הרשאות ניהול) מקבלים כיסוי בדיקות מקיף מהיום הראשון, בעוד endpoints פחות רגישים יכולים להסתפק בכיסוי בסיסי יותר בשלב הראשוני ולהתעצם עם הזמן.

טעויות נפוצות בפרודקשן

הטעות הראשונה, כפי שראינו, היא הסתמכות רק על בדיקות פונקציונליות בלי בדיקת הרשאה ייעודית שבודקת גישה חוצת-משתמשים. השנייה היא הסתמכות בלעדית על SAST או DAST בנפרד, בלי להבין שכל אחד מכסה סוג בעיות שונה ואף אחד לא מכסה הכל. השלישית היא הזנחת סריקת תלויות - הרבה חולשות מגיעות לא מקוד שכתבתם בעצמכם, אלא מספריות צד שלישי שהקוד שלכם תלוי בהן, ושמעולם לא עברו בדיקה מחדש אחרי שהוטמעו. הרביעית היא בדיקות אבטחה שרצות רק פעם אחת לפני השקה ראשונית, בלי חזרה מחזורית - קוד חדש שנוסף אחרי ההשקה לא עובר את אותה בדיקה, ופתח חדש עלול להיפתח בלי שאף אחד ישים לב. הפתרון הוא שילוב הבדיקות בתהליך הרציף (CI/CD) כפי שתואר, ולא כאירוע חד-פעמי לפני השקה, כך שכל שינוי בקוד עובר את אותה רשת הגנה באופן אוטומטי ועקבי.

מתי להשקיע במסגרת בדיקות אבטחה מלאה

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

סיכום

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

תגיות: API Security · OWASP · SAST · DAST · IDOR · Authorization Testing · Penetration Testing

← חזרה לבלוג · צור קשר