التفويض والتحكم في الوصول

المصادقة مشكلة محسومة: توجد إجابة صحيحة، وSpring Security توفّرها. أما التفويض فهو مشكلة تصميم، وهنا تكمن الثغرات المثيرة للاهتمام. لا يحتاج المهاجم إلى كسر تجزئة BCrypt لديك إذا كان بإمكانه الاطلاع على فاتورة عميل آخر بمجرد تغيير معرّف في الرابط. وتضع OWASP هذا النوع من العيوب — كسر التحكم في الوصول — على رأس تصنيفها للمخاطر.

تشترك هذه العيوب في خاصية واحدة: لا تتسبب في أي خطأ. قاعدة تفويض واسعة أكثر من اللازم لا تتعطل، بل تسمح بالوصول. وقاعدة موضوعة خلف قاعدة أخرى تبتلعها لا تُظهر أي إشارة، بل تُتجاهل ببساطة. وتعليق @PreAuthorize على دالة تُستدعى من الصنف نفسه لا يُطبَّق، فينجح الاستدعاء. وفي الحالات الثلاث تنجح الاختبارات الوظيفية، ويمر العرض التجريبي على ما يرام، والوصول مفتوح.

يعالج هذا الدرس التفويض على مستويين. الأول على مستوى الروابط (URL) باستخدام authorizeHttpRequests، وهو يحمي مدخل المبنى. والثاني على مستوى الدوال باستخدام @PreAuthorize، وهو يحمي كل غرفة — وهو وحده القادر على الإجابة عن السؤال «هل تعود هذه الفاتورة فعلًا إلى المستدعي؟»، وهو سؤال لا تستطيع قاعدة الرابط حسمه بحكم بنيتها.

سنبدأ بتمييز يجعله Spring Security ملتبسًا عن قصد، ويتعثر بسببه كل المبتدئين لمدة ساعة: التمييز بين الدور والصلاحية (authority).