Broken Object Property Level Authorization
كسر التفويض على مستوى خصائص الكائن Broken Object Property Level Authorization
API3:2023 — دمجت نسخة 2023 فئتي 'Excessive Data Exposure' و'Mass Assignment' القديمتين في فئة واحدة: غياب التحقق من الصلاحية على مستوى الحقل (property) داخل الكائن نفسه.
لها وجهان: (1) قراءة — الخادم يرجع كل حقول الكائن (بما فيها حقول حساسة كـ passwordHash أو internalNotes) بدل الحقول التي يحتاجها العميل فقط. (2) كتابة — الخادم يربط جسم الطلب (req.body) مباشرة بكائن قاعدة البيانات دون تحديد الحقول المسموح تعديلها، فيستطيع المستخدم إرسال { "role": "admin" } وترقية نفسه.
الصياغة
res.json({ id, name, email }) بدل res.json(user) | db.create({ name, email }) بدل db.create(req.body)📄 مثال
// وجه القراءة — سيئ
res.json(user); // يسرّب passwordHash, internalNotes
// وجه القراءة — جيد
res.json({ id: user.id, name: user.name, email: user.email });
// وجه الكتابة — سيئ (Mass Assignment)
const updated = await User.update(req.params.id, req.body); // المستخدم يرسل role
// وجه الكتابة — جيد
const { name, bio } = req.body; // حقول مسموحة فقط
const updated = await User.update(req.params.id, { name, bio });أهم النقاط
| النقطة | الوظيفة |
|---|---|
| الاسم القديم (2019) | Excessive Data Exposure (API3) + Mass Assignment (API6) — أصبحا فئة واحدة في 2023 |
| الحل للقراءة | DTOs أو select صريح لكل استجابة، لا ترجع الكائن كما هو من قاعدة البيانات |
| الحل للكتابة | Allowlist للحقول المسموح تعديلها بدل ربط req.body مباشرة |
💡 نصائح عملية
- GraphQL لا يحصّنك تلقائيًا من هذه الثغرة — كل حقل بالـ Schema يحتاج تحقق صلاحية مستقل
⚠️ أخطاء شائعة
- الثقة بأن 'العميل لن يرسل حقل role' — أي حقل غير محظور صراحة يُعتبر قابلاً للإرسال من مهاجم
خصائص ذات صلة
🎓 تريد فهم الصورة الكاملة خطوة بخطوة؟ ابدأ من مسار API-SECURITY الكامل بالعربي.