OWASP API Top 10: شرح أهم ثغرات API

لو بتتعامل مع APIs سواء كمطور أو بنريشن تستر، ففهم ثغرات OWASP API Top 10 مهم جدًا؛ لأن الـ API مش مجرد Endpoint بيستقبل Request ويرجع Response، لكن ممكن يكون هو الطريق المباشر لبيانات المستخدمين والعمليات الحساسة داخل التطبيق.

في الحلقة دي هنراجع أهم ثغرات OWASP API Top 10 بشكل عملي، مع التركيز على طريقة حدوث المشكلة، وتأثيرها، وإزاي تكتشفها أثناء اختبار الأمان بشكل مشروع. 🔐

🔎 يعني إيه OWASP API Top 10؟​

OWASP API Top 10 هي قائمة بأهم المخاطر الأمنية المرتبطة بواجهات برمجة التطبيقات، وبتساعد المطورين والـ Security Testers على فهم أكثر أنواع المشاكل شيوعًا وتأثيرًا في الـ APIs.
المهم هنا إن بعض الثغرات مش بتكون بسبب Bug تقني بسيط، لكن بسبب تصميم الصلاحيات أو منطق الأعمال نفسه.

---

1️⃣ BOLA - Broken Object Level Authorization​

من أشهر مشاكل الـ API هي إن التطبيق بيتأكد إن المستخدم مسجل دخول، لكنه ما بيتأكدش إنه مسموح له بالوصول للـ Object المطلوب.
مثلًا، لو الـ API بيستخدم:
/api/users/100/profile
والمستخدم قدر يغير الرقم إلى:
/api/users/101/profile
وظهر له بيانات المستخدم الآخر، فالمشكلة هنا مش في الـ ID نفسه، لكن في إن السيرفر ما عملش Authorization مناسب على مستوى الـ Object.

ليه الثغرة خطيرة؟​

لأن المهاجم ممكن يقدر يوصل إلى:

• بيانات مستخدمين تانيين.
• ملفات أو مستندات خاصة.
• طلبات شراء.
• سجلات داخلية.
• أي Objects مرتبطة بمعرفات يمكن تخمينها.

🛡️ الحل الأساسي: ما تعتمدش على إن الـ ID سري أو صعب التخمين. السيرفر نفسه لازم يتحقق من صلاحية المستخدم للوصول إلى الـ Object المطلوب.

---

2️⃣ Broken Authentication و Rate Limiting​

المصادقة الضعيفة ممكن تخلي المهاجم يستغل الـ API للوصول للحسابات أو الـ Access Tokens.
المشكلة بتزيد لما يكون مفيش Rate Limiting مناسب على العمليات الحساسة، زي تسجيل الدخول أو إرسال رموز التحقق أو تغيير كلمة المرور.
⚠️ من المشاكل اللي لازم تتراجع:

• Tokens طويلة العمر بدون داعٍ.
• عدم إبطال الـ Tokens عند الحاجة.
• محاولات تسجيل دخول غير محدودة.
• عدم وجود حماية مناسبة للعمليات الحساسة.
• السماح بعدد كبير جدًا من Requests في وقت قصير.

الـ Rate Limiting مش بديل للمصادقة القوية، لكنه طبقة حماية مهمة ضد إساءة الاستخدام ومحاولات التخمين.

---

3️⃣ Mass Assignment و Excessive Data Exposure​

Mass Assignment​

المشكلة بتحصل لما الـ API يقبل Fields من المستخدم بدون تحديد واضح للحقول المسموح بتعديلها.
مثلًا، التطبيق ممكن يسمح للمستخدم بتعديل:
name
وemail
لكن السيرفر يقبل بالخطأ Fields حساسة زي: is_admin أو: role
وده ممكن يؤدي لتغيير خصائص المفروض المستخدم ما يقدرش يتحكم فيها.

Excessive Data Exposure​

هنا المشكلة مختلفة شوية.
الـ API ممكن يرجع بيانات أكتر من اللي الواجهة محتاجاها، وبعد كده الـ Frontend يخفي بعض البيانات فقط.
وده خطر؛ لأن البيانات اللي وصلت للمتصفح ممكن يتم الوصول إليها حتى لو مش ظاهرة في الواجهة.
🔐 الأفضل إن السيرفر يرجع البيانات المطلوبة فقط بدل ما يرجع Object كامل ويعتمد على الـ Frontend في إخفاء البيانات الحساسة.

---

4️⃣ Unrestricted Resource Consumption​

مش كل هجوم على API لازم يكون هدفه سرقة البيانات.
أحيانًا الهدف هو استهلاك موارد السيرفر بشكل مبالغ فيه.
مثال على ذلك:

• رفع ملفات ضخمة بدون حدود مناسبة.
• تنزيل كمية كبيرة من البيانات.
• Requests مكلفة جدًا من ناحية المعالجة.
• Pagination بدون Limits مناسبة.
• عمليات بحث أو معالجة تستهلك CPU وMemory بشكل كبير.

لو مفيش حدود مناسبة، ممكن يؤدي ده إلى Denial of Service أو تدهور كبير في أداء التطبيق.

🛡️ الحماية هنا ممكن تشمل:

• تحديد حجم الملفات.
• وضع Limits للـ Pagination.
• Rate Limiting.
• تحديد حجم الـ Request.
• مراقبة العمليات المكلفة.
• وضع Limits مناسبة للعمليات الحسابية أو المعالجة الثقيلة.

---

5️⃣ Broken Function Level Authorization​

هنا المستخدم ممكن يكون مسجل دخول فعلًا، لكن المشكلة إن التطبيق بيسمح له باستدعاء Function أو Endpoint مش من صلاحياته.
مثلًا، ممكن يكون عندك Endpoint مخصص للإدارة، لكن الحماية تعتمد على إخفاء زر الـ Admin من الواجهة فقط.
لو المستخدم قدر يستدعي الـ Endpoint مباشرة، و السيرفر ما تحققش من صلاحياته، فهنا المشكلة.
⚠️ مهم جدًا:
إخفاء الزر في Frontend مش Authorization.
التحقق الحقيقي من الصلاحيات لازم يحصل على السيرفر لكل عملية حساسة.

---

6️⃣ Unrestricted Sensitive Business Flows​

دي من المشاكل اللي بتحتاج فهم منطق التطبيق نفسه، مش مجرد البحث عن Endpoint ضعيف.
مثال بسيط:
تطبيق تجارة إلكترونية عنده عملية شراء حساسة، والتطبيق بيفترض إن المستخدم هيستخدم الـ API بالطريقة الطبيعية من خلال الواجهة.
لو مفيش حماية مناسبة، ممكن حد يحاول إساءة استخدام الـ Business Flow عن طريق إرسال Requests بشكل آلي أو تكرار عملية معينة بطريقة غير متوقعة.

🧠 هنا اختبار الأمان لازم يركز على:

• هل العملية ممكن تتكرر بشكل غير منطقي؟
• هل فيه Limits مناسبة؟
• هل السيرفر بيتأكد من حالة العملية؟
• هل ممكن تخطي خطوة من خطوات الـ Workflow؟
• هل فيه حماية ضد Automation وإساءة الاستخدام؟

المشكلة هنا مش بالضرورة تكون ثغرة في Authentication أو Authorization، لكنها ممكن تكون في منطق الأعمال نفسه.

---

7️⃣ SSRF - Server-Side Request Forgery​

في ثغرة SSRF، المهاجم بيحاول يخلي السيرفر نفسه يرسل Request إلى Resource يختاره المهاجم.
وده ممكن يكون خطير جدًا لو التطبيق بيسمح للمستخدم بإدخال URL أو تحديد مصدر خارجي، والسيرفر بيستخدم القيمة دي بدون Validation مناسب.
في بيئات معينة، ممكن يؤدي SSRF إلى الوصول إلى:

• خدمات داخلية.
• Internal APIs.
• خدمات غير متاحة من الإنترنت مباشرة.
• Metadata Services في بعض البيئات السحابية.

⚠️ أما ربط SSRF مباشرة بـ LFI فمش دقيق كقاعدة عامة؛ SSRF وLFI ثغرتان مختلفتان، رغم إن بعض السيناريوهات أو سلاسل الاستغلال ممكن تجمع بين أكثر من ضعف.
🛡️ الحماية تعتمد على تقييد الوجهات المسموح للسيرفر بالاتصال بها، والتحقق من الـ URLs، وتطبيق Network Controls مناسبة.

---

8️⃣ Security Misconfiguration​

أحيانًا الـ API نفسه يكون مكتوب بشكل سليم، لكن إعدادات البيئة المحيطة بيه تسبب المشكلة.
أمثلة:

• Debug Mode شغال في Production.
• رسائل أخطاء بتكشف معلومات حساسة.
• إعدادات CORS غير مناسبة.
• Services غير ضرورية متاحة.
• Headers أمنية ناقصة.
• إعدادات افتراضية لم يتم تغييرها.

🔧 عشان كده مراجعة الـ API لازم تشمل التطبيق نفسه والـ Server والـ Infrastructure والإعدادات.

---

9️⃣ SQL Injection​

ثغرة SQL Injection بتحصل لما يتم دمج بيانات المستخدم داخل استعلام SQL بطريقة غير آمنة.
المشكلة ممكن تسمح للمهاجم بالتلاعب بالاستعلام بدل ما تكون البيانات مجرد Input عادي.
لكن مهم جدًا إن اختبار SQL Injection يكون على أنظمة تملكها أو عندك تصريح واضح باختبارها. 🛡️
أفضل وسائل الحماية عادةً تشمل:

• Parameterized Queries.
• Prepared Statements.
• استخدام ORM بطريقة صحيحة.
• Validation مناسبة للـ Input.
• تقليل صلاحيات حساب قاعدة البيانات.

والأهم: ما تعتمدش على Input Validation وحدها كخط دفاع أساسي ضد SQL Injection.

---

🔟 Improper Inventory Management​

الـ API ممكن يكون عنده أكتر من Version، والمشكلة إن بعض الإصدارات القديمة تفضل شغالة ومكشوفة بدون ما تكون معروفة أو مدارة بشكل صحيح.
مثلًا ممكن تلاقي: /api/v1/
وفي نفس الوقت فيه Version أحدث.
لو الـ Version القديم لسه متاح وبيحتوي على Endpoint أو منطق أضعف، فهو ممكن يتحول إلى نقطة دخول غير متوقعة.

📋 إدارة الـ API Inventory لازم تشمل:

• معرفة كل الـ API Versions الموجودة.
• معرفة الـ Endpoints النشطة.
• توثيق الـ APIs.
• تحديد الـ Deprecated APIs.
• إزالة الإصدارات غير المطلوبة.
• متابعة الـ Shadow APIs غير المعروفة للفريق.

---

🧩 إزاي تختبر API بشكل منهجي؟​

بدل ما تختبر كل Endpoint بشكل عشوائي، ابدأ بجمع صورة واضحة عن الـ API.

1. حدد الـ Endpoints​

اعرف كل الـ Routes والـ Methods المستخدمة.

2. راجع Authentication​

اختبر بشكل مشروع هل كل Endpoint محمي بالطريقة المناسبة.

3. راجع Authorization​

ما تكتفيش بالتأكد إن المستخدم Logged In.
راجع هل المستخدم مسموح له فعلًا بالوصول إلى الـ Object أو Function المطلوبة.

4. راجع الـ Input​

شوف إيه البيانات اللي الـ API بيقبلها، وهل فيه Fields حساسة ممكن يتم التحكم فيها بدون صلاحية.

5. راجع الـ Response​

تأكد إن الـ API مش بيرجع بيانات أكثر من المطلوب.

6. راجع Rate Limits​

خصوصًا على العمليات الحساسة أو المكلفة.

7. راجع Business Logic​

حاول تفهم الـ Workflow كامل، مش مجرد كل Request لوحده.

8. راجع الإصدارات​

تأكد إن الإصدارات القديمة والـ Endpoints غير المستخدمة مش بتفضل مكشوفة بدون داعٍ.

---

🎥 فيديو شرح OWASP API Top 10​

لو عايز تشوف الشرح العملي للحالات دي بشكل مرئي، تقدر تتابع الفيديو:

الفيديو بيركز على فهم أنواع الثغرات وسيناريوهات استغلالها، وده مفيد سواء كنت Developer أو بتتعلم API Security وPenetration Testing.

---

❓ الأسئلة الشائعة​

-----------------

ما هو OWASP API Top 10؟​

هو تصنيف من OWASP لأهم المخاطر الأمنية المرتبطة بواجهات برمجة التطبيقات، وبيساعد المطورين وفرق الأمن على تحديد المشاكل اللي محتاجة مراجعة وحماية.

ما الفرق بين BOLA وBroken Function Level Authorization؟​

BOLA بتتعلق بالوصول غير المسموح إلى Object معين، بينما Broken Function Level Authorization بتتعلق بالسماح للمستخدم بتنفيذ Function أو Endpoint مش من صلاحياته.

هل Authentication وحده كفاية لتأمين API؟​

لا. تسجيل الدخول بيثبت هوية المستخدم، لكن لازم كمان يكون فيه Authorization مناسب يحدد العمليات والبيانات اللي مسموح للمستخدم بالوصول إليها.

ليه API Versions القديمة ممكن تكون خطيرة؟​

لأن Version قديم ممكن يفضل شغال رغم إنه غير مدعوم أو يحتوي على منطق أمني أضعف من الإصدار الحالي، لذلك لازم يكون عندك Inventory واضح لكل الإصدارات والـ Endpoints.

هل SSRF وLFI نفس الثغرة؟​

لا. هما ثغرتان مختلفتان. SSRF بتخلي السيرفر يرسل Requests إلى وجهات يحددها المهاجم، بينما LFI مرتبطة بإجبار التطبيق على قراءة ملفات محلية بطريقة غير آمنة.