تسجيل الدخول إلى التطبيق لا يعني أن كل سجل فيه متاح للمستخدم. في نظام يخدم عدة شركات، قد يملك موظف صلاحية قراءة فواتير شركته فقط، لكن واجهة API تقبل معرّف فاتورة دون التحقق من صاحبها. اختبار صلاحيات API يجب أن يتناول المورد نفسه، والعملية المطلوبة، وحدود الشركة، بدل الاكتفاء باختبار صفحة الدخول.
ما الفرق بين الهوية وصلاحية المورد؟
تصف OWASP مشكلة Broken Object Level Authorization بأنها قصور في التحقق من صلاحية المستخدم على الكائن الذي يحدده الطلب. المعرّف الطويل أو غير المتسلسل لا يغني عن هذا الفحص. وفي Laravel يمكن تنظيم قرارات الوصول باستخدام Policies وGates؛ لكن وجودها في المشروع لا يثبت تطبيقها على كل مسار، لذلك يلزم اختبار السلوك الفعلي.
ابدأ بتعريف الفاعل والمورد والعملية. مثال ذلك: موظف مبيعات، فرصة بيع، قراءة التفاصيل. أضف نطاق الشركة والفرع وملكية الحساب إن كانت جزءًا من القرار. وثّق حالات المشاركة المشروعة حتى لا تمنع تعاونًا مقصودًا، وحدّد الاستثناءات التي تحتاج دورًا إداريًا صريحًا.
جهّز حسابات وموارد تجريبية مستقلة
داخل بيئة اختبار تملك تفويضًا لاختبارها، أنشئ شركتين تجريبيتين وموارد معروفة لكل منهما. استخدم حسابات تمثل الأدوار الفعلية، دون بيانات عملاء حقيقيين. لكل طلب مسموح، اكتب طلبًا مقابلًا يجب رفضه. لا تغيّر معرّفات موارد الغير على خدمة عامة لا تملك إذنًا لاختبارها.
| الفحص | النتيجة المتوقعة |
|---|---|
| قراءة سجل من الشركة المخوّلة | بيانات ضمن حدود الدور |
| قراءة سجل من الشركة التجريبية الأخرى | رفض دون تفاصيل المورد |
| تصدير قائمة تحتوي على موارد مختلفة | كل عنصر يلتزم بنطاق الوصول |
| فتح مرفق مباشر | نفس قواعد الوصول إلى سجله |
| تعديل مورد بعد نقل ملكيته | قرار يعتمد على الحالة الحالية |
اختبر المسارات التي تُنسى عادة
لا توقف المراجعة عند طلب التفاصيل. افحص البحث والتصفية والتصدير والإحصاءات والعمليات الجماعية وروابط تنزيل الملفات. قد تُحمى صفحة السجل بينما تعرض قائمة البحث عنوانه أو تسرب أعدادًا تخص شركة أخرى. حتى الرسالة التي تقول إن المورد موجود لكنها ترفض تعديله يمكن أن تكشف معلومة؛ اتفق على أسلوب الأخطاء وفق حساسية النظام.
راجع أيضًا الحقول الداخلية. منع قراءة سجل شركة أخرى لا يمنع بالضرورة تعديل حقل ملكية داخل سجل مسموح. اختبر إرسال حقل شركة أو دور أو مسؤول حساب غير معروض في الواجهة، وتحقق من أن السيرفر يقبل الحقول المسموحة فقط. واجهة المستخدم ليست جهة إنفاذ للصلاحيات.
حوّل الاختبار إلى تغطية تمنع الرجوع
لكل قاعدة مهمة، احتفظ باختبار مسموح وآخر مرفوض مع سبب القرار. افحص الاستجابة وعدم حدوث التعديل في قاعدة البيانات، وليس رمز HTTP فقط. إذا عدّلت اسم دور أو طريقة ربط المستخدم بالشركة، أعد الاختبارات المرتبطة بالقوائم والملفات والعمليات الجماعية. راجع سجل التدقيق لعمليات الإدارة التي تغيّر حدود الوصول.
في سيناريو اختبار توضيحي، يمتلك مدير فرع صلاحية رفع تقرير لفرعه، ثم ينتقل موظف إلى فرع آخر. ينبغي أن يعتمد الطلب الجديد على الصلاحيات الحالية لا على قرار قديم محفوظ دون مراجعة. سجّل سياسة التحديث والتخزين المؤقت التي اختبرتها حتى يعرف الفريق ما الذي يضمنه الاختبار.
أدرج المصفوفة ضمن المراجعة والاستشارات التقنية قبل تشغيل تكامل جديد، واربطها بتصميم أنظمة إدارة الشركات. النتيجة المطلوبة حدود وصول مثبتة لكل عملية مهمة، لا مجرد حساب يعمل وكلمة مرور صحيحة.
