ממשקי ה-API הם צינורות הדם של האפליקציה המודרנית — הם מעבירים בין השירותים שלכם נתוני משתמשים, פרטי תשלום, טוקנים ומידע עסקי רגיש. בדיוק בגלל זה הם גם היעד המועדף על תוקפים. דו״ח OWASP API Security Top 10 מצביע שוב ושוב על אותן חולשות: הרשאות שבורות, אימות חלש וחשיפת מידע יתר — כשלים שלרוב לא נראים במבחני חדירה קלאסיים של אתר האינטרנט. במאמר הזה נעבור על השיטה שבה בודקים API בצורה מקצועית, מה בודקים בפועל, ואיך יודעים שאתם באמת מוגנים.

מה זה מבדק חדירות API ולמה זה שונה מבדיקת אתר רגילה

מבדק חדירות API הוא בדיקה מבוקרת שבה חוקר אבטחה מנוסה מתקיף את ממשקי ה-REST / GraphQL / gRPC של המערכת שלכם באותן טכניקות שבהן ישתמש תוקף אמיתי — רק שבמקום לגנוב מידע, הוא מתעד את החולשות ומעביר אותן אליכם לתיקון. בניגוד לבדיקה של דפי HTML, כאן אין ממשק גרפי שמסתיר לוגיקה: התוקף מדבר ישירות עם השרת, ולכן כל טעות קטנה בהרשאה או באימות הופכת לפרצה גדולה.

ההבדלים המרכזיים מבדיקת אפליקציית ווב:

  • Business Logic — קל לעקוף לוגיקה עסקית כשמדלגים על ה-UI (למשל לשנות מחיר בבקשה, או להזמין בשם משתמש אחר).
  • Object-Level Authorization (BOLA/IDOR) — החולשה מספר 1 ב-OWASP API Top 10: החלפת מזהה אחד בבקשה חושפת נתונים של משתמש אחר.
  • Mass Assignment — שדות שלא היו אמורים להיות עריכה (כמו is_admin) עוברים דרך גוף הבקשה.
  • Rate Limiting — היעדר הגבלה מאפשר brute-force על סיסמאות, קופונים ו-OTP.

המתודולוגיה: איך בפועל מריצים מבדק חדירות API

מבדק מקצועי לא מסתכם ב-Burp Suite שרץ באוטומט. הוא בנוי מארבעה שלבים:

  1. Discovery & Enumeration — מיפוי כל ה-endpoints, גם אלה שלא מתועדים ב-Swagger. משתמשים ב-ffuf, Kiterunner, ניתוח קוד JS של הפרונט וניתוח תעבורה חיה.
  2. Authentication & Session — בדיקת JWT (alg=none, מפתחות חלשים, אי-פקיעה), OAuth misconfig, cookies ללא HttpOnly/Secure, refresh token שלא מתחלף.
  3. Authorization — הליבה של כל בדיקה: לשחק עם token של משתמש A מול משאבים של משתמש B. כאן נופלות רוב המערכות.
  4. Injection & Input Handling — SQLi, NoSQLi, SSRF, XXE, deserialization, ובעולם של היום גם Prompt Injection כשה-API מוזן ל-LLM.

מה בודקים בפועל — צ׳ק-ליסט מקוצר

  • האם אפשר להחליף userId ב-URL ולראות נתונים של אחרים?
  • האם ה-JWT באמת מאומת בכל בקשה, או רק בכניסה?
  • האם endpoint של הרשמה חושף אם אימייל קיים במערכת (User Enumeration)?
  • האם יש הגבלת קצב על /login, /forgot-password ו-/verify-otp?
  • האם שדות רגישים מוחזרים גם כשהלקוח לא ביקש אותם (Excessive Data Exposure)?
  • האם קיימת בדיקת סוגי קבצים אמיתית ב-upload, או רק בדיקת סיומת?
  • האם CORS מוגדר עם * על endpoints מאומתים?

מי צריך את זה — ומתי

כל ארגון שמפעיל API שנחשף לאינטרנט הציבורי חייב מבדק חדירה תקופתי — לפחות פעם בשנה, ואחרי כל שינוי משמעותי בארכיטקטורה. חברות פינטק, בריאות דיגיטלית, SaaS ו-e-commerce מחויבות לזה גם רגולטורית (PCI-DSS, HIPAA, ISO 27001, תקן הגנת הפרטיות בישראל). גם סטארטאפ בשלב מוקדם ירוויח מבדיקה לפני גיוס — משקיעים מתקדמים דורשים דו״ח PT עדכני כחלק מ-Due Diligence טכני.

למי לפנות לביצוע המבדק

העבודה הזאת דורשת חוקרים שמתמחים ספציפית ב-API — לא כל חברת סייבר כללית תזהה BOLA עמוק בשכבת ה-GraphQL. חברה שמתמחה בזה, מכירה את הכלים הרלוונטיים (Postman, mitmproxy, Burp Pro עם Autorize, custom scripts) ויודעת לתרגם ממצא טכני לפעולה ברורה לצוות הפיתוח, היא מבדק חדירות API של Redentry — צוות שמבצע בדיקות עומק על מערכות בענן, מיקרו-שירותים ופלטפורמות SaaS, ומספק דו״ח מפורט עם רמות סיכון, PoC ותוואי תיקון קונקרטי.

איך מתכוננים למבדק כדי להוציא ממנו את המקסימום

  1. ספקו תיעוד עדכני של ה-API (OpenAPI/Swagger, Postman Collection).
  2. הכינו שני משתמשי בדיקה לפחות עם הרשאות שונות — זה קריטי לבדיקות אוטוריזציה.
  3. הגדירו סביבת Staging זהה לפרודקשן, כולל DB עם דאטה מציאותי.
  4. הקצו איש קשר טכני לזמינות מהירה במקרה שהבדיקה גורמת לרעש בלוגים.
  5. הגדירו scope ברור: אילו מערכות בפנים, אילו מחוץ לגבולות (למשל שירותי צד שלישי).

אחרי הדו״ח — מה עושים עם הממצאים

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

סיכום

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