صلاحيات تطبيق الويب: كيف تضمن أن كل عميل يرى طلباته فقط؟

وجود صفحة تسجيل دخول لا يضمن خصوصية حسابات العملاء. قد يدخل العميل بصورة صحيحة، ثم يصل إلى طلب لا يخصه إذا اكتفى الخادم بالتحقق من وجود جلسة. السؤال المهم بعد «من هذا المستخدم؟» هو «هل يحق له تنفيذ هذا الإجراء على هذا السجل، الآن؟». هذا الدليل يساعد صاحب المنتج والمطور على كتابة الإجابة قبل أن تتوزع الصلاحيات عشوائيًا بين الأزرار والصفحات.

اكتب سياسة عمل، لا مجرد أسماء أدوار

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

عند مراجعتها قد تقرر الشركة أن المنسق يحتاج الاطلاع على حالة السداد دون رقم الفاتورة أو العنوان. سجّل هذا التفصيل بدل منحه «وصولًا كاملًا» لأنه موظف. توصي إرشادات OWASP للصلاحيات بالحد الأدنى من الامتيازات، والمنع الافتراضي، والتحقق في كل طلب. ابدأ بصلاحيات ضيقة يمكن تفسيرها ثم أضف ما تثبت الحاجة إليه.

اربط المستخدم بالسجل نفسه

في المنصة الافتراضية، الطلب PR-204 يخص العميل سلمى ضمن الشركة ألف. وجود دور client لا يكفي لقراءته، لأن للعميل سامر الدور نفسه. يجب أن تمر القراءة عبر علاقة موثوقة بين المستخدم والطلب. ويشمل ذلك صفحة التفاصيل ومسار تنزيل الملف والرسائل ونسخة PDF، لا قائمة الطلبات فقط.

توضح وثائق OWASP حول IDOR أن المعرّفات المعقدة لا تعوض فحص الوصول إلى السجل. يمكنك إبقاء رقم PR-204 مريحًا للمحادثة ومعرّف داخلي عشوائي للتنظيم؛ لا تجعل أيًا منهما كلمة مرور. ابحث ضمن نطاق السجلات المسموح بها، واستخرج هوية المستخدم من سياق جلسة موثوق، لا من قيمة ownerId يرسلها المتصفح.

مثال قرار قابل للمراجعة

عند طلب تنزيل مسودة تصميم، قد يكون القرار في مثالنا: الجلسة فعالة، والملف مرتبط بطلب قائم، والمستخدم إما صاحب الطلب أو منسق مسند إليه حاليًا، والملف معلّم بأنه قابل للمشاركة مع هذا الطرف. فالمسودة الداخلية ليست تلقائيًا ملفًا للعميل. إذا كانت إحدى العلاقات ناقصة، يتوقف التنزيل دون إعادة محتوى الملف أولًا ثم إخفائه بالواجهة.

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

لا تنس حدود الشركات والمهام الخلفية

قد يعمل الموظف مع شركتين في المنصة نفسها. اختيار الشركة من القائمة لا يمنحه عضوية فيها. يجب أن يحمل الطلب سياق شركة موثوقًا وتتقيد به الاستعلامات. ويتناول دليل OWASP للأنظمة متعددة المستأجرين عزل البيانات خارج واجهة العرض أيضًا، بما يشمل التخزين المؤقت والمهام الخلفية.

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

احمِ الحقول الحساسة وتغيّر الصلاحيات

السماح بتعديل عنوان الطلب لا يعني السماح بتغيير مالكه أو قيمته المدفوعة. استخدم قائمة الحقول القابلة للتحرير لكل إجراء، وهي معالجة تشرحها إرشادات منع Mass Assignment. في نموذج المنصة يمكن للعميل تعديل وصف المسودة، بينما يأتي اعتماد الدفع من مسار مختلف ومصرح به.

لا تخلط كذلك بين حماية الجلسة وقرار الصلاحية. راجع إدارة الجلسات وحماية CSRF بحسب بنية تطبيقك؛ وجود إحداهما لا يحل محل الأخرى. عند إلغاء عضوية موظف، حدد كيف تصبح الإزالة نافذة في الجلسات القائمة، وكيف تُلغى أو تُرفض المهام الحساسة التي لم تبدأ بعد. هذا قرار تشغيلي يجب اختباره لا مجرد تغيير في شاشة الإدارة.

مصفوفة اختبار صغيرة تمنع فراغات كبيرة

استخدم حسابات وبيانات اختبار تملكها داخل بيئة مصرح بها. أنشئ عميلين وشركتين، وموظفًا مسندًا وآخر غير مسند. لكل إجراء حساس اختبر المسموح والممنوع، ثم اختبر الحالة بعد سحب الصلاحية. لا يكفي أن يختفي الزر؛ أرسل الطلب إلى الخادم ضمن الاختبار وتأكد من عدم حدوث أثر ومن عدم خروج بيانات غير مسموحة.

• القراءة: تفاصيل الطلب، البحث، العدادات، المرفقات والتصدير.
• التعديل: النصوص، الإسناد، الحذف، وحالات الاعتماد.
• المشاركة: دعوة عضو، سحب دعوته، وروابط التنزيل المؤقتة.
• التزامن: تغيير الإسناد أثناء محاولة إجراء محمي.
• الفشل: تعذر قراءة سياسة الوصول يجب ألا يتحول إلى سماح تلقائي.

أدخل هذه الحالات في الاختبارات الآلية للموقع، وسجّل محاولات التغيير الحساسة دون نسخ الرسائل والمرفقات الشخصية إلى السجلات. حدد مسؤول مراجعة الصلاحيات عندما يغادر موظف أو يتغير نطاق المشروع، واجعل المراجعة جزءًا من الصيانة.

هل يكفي دور admin واحد؟ قد يكفي في فريق صغير جدًا إذا كانت مسؤولياته مقصودة ومحدودة العدد. عندما يتشارك الدعم والفوترة والتحرير، افصل الأفعال المطلوبة بدل تكثير أسماء الأدوار بلا معنى. المهم أن يستطيع صاحب العمل شرح سبب كل صلاحية، وأن يثبت الاختبار أن الخادم يطبق هذا السبب.

أُعد هذا المقال بمساعدة الذكاء الاصطناعي؛ أُدرجت المراجع التقنية للتحقق من التفاصيل.