يسجل “بوب” (Bob) دخوله إلى واجهة برمجة تطبيقات (API) البيئة التجريبية باستخدام حسابه الصالح، ويطلب المسار GET /invoices/inv_100، فيتلقى فاتورة “أليس” (Alice). لم يقم المهاجم بسرقة رمز وصول (token)، أو تجاوز عملية تسجيل الدخول، أو تخمين كلمة المرور؛ بل قام “بوب” بتغيير مُعرِّف الكائن (object identifier) في المسار، وهو ما قبله الخادم دون التحقق مما إذا كانت الفاتورة inv_100 مملوكة لـ “بوب” أم لا. ومن ثم، فإن السؤال الذي يطرحه المدافع أكثر تحديداً وفائدة من مجرد التساؤل عما إذا كانت عملية تسجيل الدخول تعمل بشكل صحيح: فمع كل طلب، هل تتحقق واجهة برمجة التطبيقات (API) من أن الطرف المُصادَق عليه (authenticated principal) يمتلك صلاحية إجراء هذه العملية على هذا الكائن؟
يتمثل النظام الذي نعمل عليه في واجهة برمجة تطبيقات (REST API) صغيرة تتضمن المسارات التالية: POST /login و GET /invoices/{invoiceId} و PUT /invoices/{invoiceId} و GET /admin/audit. تمتلك “أليس” الفاتورة inv_100 ويمتلك “بوب” الفاتورة inv_200، بينما يمتلك المسؤول صلاحية قراءة سجلات التدقيق (audit records). تحدد نمذجة التهديدات العناصر التي يسيطر عليها المهاجم بالفعل، والحدود التي يتجاوزها الطلب، وما يسعى المهاجم لتحقيقه، والقرار الذي يجب أن يتخذه الخادم لإيقاف الطلب. في هذه الحالة، يسيطر “بوب” على طلبه المُصادَق عليه وعلى مُعرِّف الفاتورة (invoiceId)؛ وهو يسعى للحصول على فاتورة “أليس”؛ لذا يجب أن ترفض آلية التفويض (authorization) الوصول قبل خروج البيانات من مخزن البيانات.
تثبت عملية المصادقة (authentication) أن الطلب صادر عن “بوب”، ولكن تظل هناك حاجة لاتخاذ قرار بشأن التفويض (authorization) لتحديد ما إذا كان يحق لـ “بوب” قراءة الفاتورة inv_100. إن التعامل مع هذين القرارين كإجراء تحقق واحد يؤدي إلى حدوث ثغرة أمنية، لأن الهوية الصالحة لا تعني بالضرورة وجود ملكية أو صلاحيات إدارية. يتمثل هدفنا خلال هذه الدورة في تعزيز أمان واجهة برمجة التطبيقات هذه وإثبات صمود كل حد أمني عند الاختبار. يوضح المخطط التالي الحدود التي يتجاوزها “بوب”.
يوضح هذا الرسم البياني سبب إمكانية اجتياز الطلب لمرحلة المصادقة (Authentication) مع فشله في مرحلة التفويض (Authorization) أو الوصول إلى البيانات. يصبح مُعرِّف الكائن (Object identifier) خطيراً فقط عندما تستخدمه واجهة برمجة التطبيقات (API) لجلب سجل ما دون ربط ذلك السجل بالطرف المُصادَق عليه (المستخدم).
يُعرف غياب التحقق من الملكية بالثغرة المصنفة API1:2023 - التفويض المعطّل على مستوى الكائن (Broken Object Level Authorization)، أو اختصاراً BOLA، ضمن قائمة OWASP لأهم 10 مخاطر أمنية في واجهات برمجة التطبيقات لعام 2023. تتطلب أي نقطة نهاية (endpoint) تستقبل مُعرِّف كائن يتحكم فيه العميل اتخاذ قرار بشأن التفويض المتعلق بذلك الكائن. تُعد العمليتان GET /invoices/inv_100 و PUT /invoices/inv_100 عمليتين منفصلتين، ولذا تتطلب كل منهما قراراً مستقلاً حتى وإن كانت كلتاهما تشيران إلى الفاتورة نفسها.
تتمحور المخاطر الأولية الأخرى حول مسار الطلب ذاته. تتعلق الثغرة API2:2023 - المصادقة المعطّلة (Broken Authentication) بمدى دقة واجهة برمجة التطبيقات في تحديد هوية المستخدم (مثل “Bob”). وتتعلق الثغرة API3:2023 - التفويض المعطّل على مستوى خصائص الكائن (Broken Object Property Level Authorization) بما إذا كانت استجابة النظام المتعلقة بفاتورة مسموح بالوصول إليها تكشف أو تقبل حقولاً لا ينبغي للمستخدم الوصول إليها، مثل حقل داخلي يحدد “حد الموافقة” (approvalLimit). أما الثغرة API4:2023 - استهلاك الموارد غير المقيد (Unrestricted Resource Consumption) فتتعلق بقيام المستخدم بإرسال طلبات مكلفة (تستهلك موارد كبيرة) بوتيرة تؤدي إلى استنفاد السعة أو بدء عمليات لاحقة تتطلب تكلفة مالية. وأخيراً، تتعلق الثغرة API5:2023 - التفويض المعطّل على مستوى الوظيفة (Broken Function Level Authorization) بقدرة المستخدم على الوصول إلى المسار GET /admin/audit رغم افتقاره إلى الصلاحيات الإدارية اللازمة.
تُحدث كل فئة من هذه الفئات تغييراً في جزء مختلف من الطلب، لكنها جميعاً تختبر ما إذا كان الخادم يفرض حدوداً أمنية بدلاً من الاكتفاء بالوثوق بمدخلات العميل، أو الرمز المميز (token) وحده، أو اسم نقطة النهاية. ويقارن الجدول بين التغيير الذي يجريه المهاجم، والنتيجة المراد حمايتها، والأدلة التي يحتاجها المدافعون عن النظام.