API Security
בדיקת חדירות לממשקי API
ב־API אין ממשק שמסתיר דברים. ההרשאות, המבנה של התשובות והפרמטרים הם ההגנה עצמה — ושם נמצאות החולשות המשמעותיות.
מה נבדק בממשקי API
הרשאות ברמת אובייקט
האם החלפת מזהה בבקשה מחזירה נתונים של משתמש, ארגון או לקוח אחר.
הרשאות ברמת פונקציה
האם נקודת קצה ניהולית או פעולה מיוחדת נגישה למשתמש עם תפקיד רגיל.
אימות וניהול טוקנים
תוקף, רענון, ביטול, והתנהגות המערכת מול טוקן שפג או שהורכב מחדש.
חשיפת נתונים בתשובות
שדות פנימיים, נתוני משתמשים אחרים או מידע שלא נחוץ לממשק שצורך את הנתונים.
ולידציה של פרמטרים
טיפול בקלט לא צפוי, סינון, עימוד, מיון ומגבלות קצב היכן שרלוונטי.
תיעוד מול מציאות
השוואת מפרט ה־API לנקודות הקצה שזמינות בפועל, כולל גרסאות ישנות שנשארו פתוחות.
מה עוזר לבדיקה להיות מדויקת
- רשימת סוגי משתמשים ותפקידים, ומה כל תפקיד אמור לראות
- תיעוד OpenAPI / Swagger או אוסף בקשות (Postman)
- חשבונות בדיקה נפרדים לכל תפקיד, ושני ארגונים לבדיקת בידוד
- הקשר עסקי: מה נחשב פעולה רגישה במערכת שלכם
- הגדרה מה מחוץ להיקף, כולל ספקי צד שלישי
למה הקשר עסקי קריטי ב־API
נקודת קצה שמחזירה נתונים יכולה להיראות תקינה לחלוטין מבחינה טכנית, ובכל זאת לחשוף מידע שלא היה צריך להיות זמין לאותו תפקיד. כלים לא יודעים מה הכלל העסקי שלכם; בודק אנושי שמבין את המודל יכול לזהות פער כזה ולאמת אותו.
לכן הבדיקה מתבצעת עם מספר חשבונות ותפקידים, ובודקת מה כל אחד מהם מצליח להשיג בפועל בהיקף שאושר.
שאלות נפוצות על בדיקת API
אין לנו תיעוד API. אפשר בכל זאת לבדוק?
האם נדרשות מספר סביבות או חשבונות?
האם בדיקת API כלולה בבדיקה של האפליקציה?
בואו נבין מה צריך לבדוק ב־API שלכם
שלחו פרטים ונחזור אליכם להגדרת היקף מדויק.