المصادقة تخبرك من يكون الشخص. أما التفويض فيخبرك بما يُسمح له بفعله. يُخلط بينهما باستمرار، والفجوة بينهما مصدر معظم نتائجنا عالية الخطورة في واجهات API.
لماذا المصادقة ليست تفويضًا
الرمز الصالح أو ملف تعريف الجلسة يثبت الهوية، لكنه لا يقول شيئًا عن أحقية هذه الهوية في عرض الفاتورة رقم 4821، أو حذف مشروع فريق آخر، أو استدعاء نقطة نهاية مخصصة للمسؤولين. قد تمتلك الواجهة مصادقة مثالية — رموزًا موقّعة بشكل سليم، وصلاحية قصيرة، ومصادقة متعددة العوامل — وتظل تسرّب بيانات كل عميل إلى كل عميل آخر، لأن لا شيء في الخادم يتحقق من الملكية قبل إعادة السجل.
أنماط شائعة نراها في الواقع
النسخة الأكثر تكرارًا هي تعداد معرّفات الكائنات ببساطة: زِد المعرّف الرقمي في الرابط، فتحصل على بيانات شخص آخر. وأقل وضوحًا بقليل خلل التفويض على مستوى الوظائف — مستخدم عادي يستدعي نقطة نهاية لم يُقصد الوصول إليها إلا من لوحة الإدارة، لأن نقطة النهاية نفسها لا تتحقق من دور المستدعي. كلاهما سهل الاستغلال بمجرد اكتشافه، وكلاهما يتسلل باستمرار من الفحص الآلي لأن الطلب يبدو مشروعًا تمامًا.
كيف نختبر ذلك
هذا عمل يدوي بطبيعته. نرسم كل حدود الأدوار والمستأجرين التي يُفترض أن يفرضها التطبيق، ثم نحاول بشكل منهجي تجاوزها — عرض بيانات مستخدم آخر، واستدعاء نقاط نهاية دور آخر، والتصرف عبر المستأجرين. يمكن لأداة الفحص أن تخبرك أن نقطة النهاية موجودة وتعيد 200، لكنها لا تستطيع أن تخبرك أن هذا الرد ما كان يجب أن يحدث لهذا المستخدم تحديدًا.
أخطر ثغرات التفويض لا تبدو كهجمات. بل تبدو كطلب عادي وصالح — لكن للمورد الخطأ.
إذا ركزت مراجعتك الأمنية الأخيرة على المصادقة — الدخول الموحّد والمصادقة متعددة العوامل والتعامل مع الرموز — ولم تختبر تحديدًا حدود التفويض بين المستخدمين والأدوار والمستأجرين، فهناك احتمال كبير أن نتيجتك القادمة تنتظرك هنا.