אבטחת API בישראל: OWASP API Security Top 10 ומה CTO חייב לבדוק לפני עלייה ל-Production

למה אבטחת API היא הבעיה שהופכת יקרה מדי מאוחר?

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

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

1. Broken Object Level Authorization (BOLA)

הפגיעות הנפוצה ביותר ב-API בעולם. משתמש מבקש /api/orders/1234 ומקבל הזמנה של משתמש אחר, כי ה-API בדק שהמשתמש מחובר אבל לא בדק שהוא בעל ההזמנה הספציפית הזו. בניית אפליקציית API בטוחה דורשת בדיקת Ownership על כל Object שמוחזר — לא רק בדיקת Authentication כללית.

2. Broken Authentication

JWT Tokens בלי תפוגה, Refresh Tokens שלא מתבטלים בהתנתקות, או Endpoints לאיפוס סיסמה בלי Rate Limiting — כל אלה פותחים דלת ל-Account Takeover. הקמת API מקצועית כוללת Token Expiry קצר, Refresh Token Rotation, ו-Rate Limiting אגרסיבי על כל Endpoint שקשור להתחברות.

3. Broken Object Property Level Authorization

ה-API מחזיר את כל השדות של Object — כולל שדות פנימיים כמו Internal Notes, Cost Price, או Admin Flags — כשהלקוח היה צריך רק שם ומחיר. בניית אפליקציות API עם DTOs מוגדרים (ולא Serialization ישיר של מודל ה-Database) מונעת חשיפת מידע לא מכוון.

4. Unrestricted Resource Consumption

API בלי הגבלה על גודל Response, מספר Requests, או עומק Query הופך פתוח ל-Denial of Service ולעלויות Cloud מנופחות. Rate Limiting, Pagination חובה, ו-Query Complexity Limits (ב-GraphQL בפרט) הם קו ההגנה הראשון.

5. Broken Function Level Authorization

משתמש רגיל שמצליח לקרוא ל-Endpoint אדמיניסטרטיבי כי ה-API בדק Authentication אבל לא בדק Role. כל הקמת API חייבת שכבת Authorization נפרדת מה-Authentication — RBAC או ABAC, נבדק בכל Endpoint, לא רק בשכבת ה-UI.

6-10: השאר שלא פחות קריטיים

• Server-Side Request Forgery: API שמקבל URL מהלקוח ופונה אליו בלי Validation, נגד Internal Network.
• Security Misconfiguration: CORS פתוח מדי, Headers חסרים, Error Messages שחושפים Stack Traces ל-Production.
• Improper Inventory Management: גרסאות ישנות של API (v1) שנשארות פעילות ולא מתועדות, ונשארות פתוחות לפגיעויות שתוקנו ב-v2.
• Unsafe Consumption of APIs: אמון עיוור בנתונים מ-API של צד שלישי בלי Validation — הופך את הפגיעות של הצד השלישי לפגיעות שלכם.
• Injection ו-Business Logic Abuse: SQL/NoSQL Injection קלאסי, וגם ניצול לוגיקה עסקית (למשל: החלת קופון פעמים רבות דרך קריאות API חוזרות).

Checklist מעשי לפני Production

1. כל Endpoint עובר בדיקת Ownership (BOLA) — לא רק Authentication.
2. DTOs מוגדרים לכל Response — אין Serialization ישיר של מודל ה-Database.
3. Rate Limiting על כל Endpoint, אגרסיבי במיוחד על Authentication ו-Password Reset.
4. Penetration Test עצמאי (לא רק Automated Scan) לפני עלייה ל-Production.
5. Logging ו-Alerting על ניסיונות גישה חשודים — לא רק על שגיאות שרת.

אנחנו מיישמים את כל 10 הסעיפים של OWASP API Security Top 10 כחלק סטנדרטי מכל הקמת API שלנו — לא כתוספת בתשלום. קראו את המדריך המקיף לבניית אפליקציות API ב-2026 או את 25 השאלות שכל CTO חייב לבדוק להעמקה נוספת.

הצעד הבא

מתכננים הקמת API או רוצים לבדוק את רמת האבטחה של API קיים? קבעו שיחת ייעוץ טכני חינם — נבחן את הארכיטקטורה הנוכחית שלכם מול OWASP API Security Top 10 ונציג ממצאים ראשוניים.