شرح ثغرة التحكم في الوصول المعطوب (OWASP A01) — 2026

يحتلّ التحكم في الوصول المعطوب المرتبة الأولى في OWASP Top 10 — فهو أكثر ثغرات الويب الخطيرة شيوعًا. وببساطة: يستطيع المستخدمون فعل أو رؤية أشياء لا ينبغي السماح لهم بها.

الفكرة الجوهرية

تجيب المصادقة عن سؤال «مَن أنت؟» بينما يجيب التفويض عن «ماذا يُسمح لك بفعله؟» والتحكم في الوصول المعطوب هو فشل في التفويض: يتحقق التطبيق ممّن أنت لكنه لا يتحقق مما إذا كنت مخوّلًا لتنفيذ إجراء معيّن أو رؤية مورد معيّن.

الأشكال الشائعة

• IDOR (مرجع كائن مباشر غير آمن) — تغيّر معرّفًا في رابط أو طلب (مثل /account/123 ← /account/124) فترى بيانات شخص آخر لأن التطبيق لم يتحقق من الملكية.
• تصعيد الصلاحيات (Privilege Escalation) — يصل مستخدم عادي إلى وظائف مخصّصة للمسؤولين فقط (بتخمين رابط إداري أو العبث بمعامل الدور مثلًا).
• غياب الفحوص على مستوى الوظيفة — تُخفي الواجهة إجراءً، لكن الـ API الكامنة تسمح به إذا استدعيته مباشرةً.
• التصفّح القسري (Forced Browsing) — الوصول إلى صفحات أو ملفات ينبغي أن تتطلب إذنًا، بمجرّد معرفة مسارها.

لماذا هو شائع إلى هذا الحد

كثيرًا ما يفرض المطوّرون التحكم في الوصول داخل الواجهة (بإخفاء الأزرار) لكنهم ينسون فرضه على الخادم لكل طلب. والمهاجمون لا يستخدمون واجهتك — بل يستدعون الـ API مباشرةً. وإذا لم يكن التحقق من جانب الخادم فهو ليس تحققًا.

كيف نمنعه

1. افرض التفويض على الخادم، لكل طلب — لا تعتمد أبدًا على إخفاء الأشياء في الواجهة.
2. امنع افتراضيًا (Deny by Default) — امنح الوصول صراحةً لا ضمنيًا.
3. تحقّق من الملكية — تأكّد أن المستخدم المسجّل يملك فعلًا المورد الذي يطلبه (يوقف IDOR).
4. استخدم آلية تحكم مركزية في الوصول بدل فحوص متفرقة عشوائية.
5. لا تثق بالأدوار/المعرّفات القادمة من العميل — تحقّق منها على الخادم.
6. سجّل إخفاقات التحكم في الوصول ونبّه عند ظهور أنماط.

كيف يُكتشف

يفحص المختبِرون بالتلاعب بالمعرّفات والمعاملات واستدعاء النقاط النهائية مباشرةً — وهو تمامًا ما تسهّله أدوات مثل Burp Suite ضمن اختبار اختراق مصرّح به. ولأنه قائم على المنطق، فهو أيضًا مثال ممتاز على المجال الذي يضيف فيه كلٌّ من الاختبار البشري واختبار الذكاء الاصطناعي قيمة.

تعلّم أمن تطبيقات الويب من البداية إلى النهاية، مجانًا، في أكاديمية Pentevo.