API3:2023 – Broken Object Property Level Authorization (BOPLA)؛ افشای فیلدهای حساس و تغییر غیرمجاز داده‌ها در API

مقدمه

بسیاری از توسعه‌دهندگان تصور می‌کنند اگر دسترسی به یک شیء (Object) کنترل شود، دیگر مشکل امنیتی خاصی وجود نخواهد داشت. اما در عمل، حتی زمانی که کاربر به یک شیء مجاز دسترسی دارد، ممکن است بتواند فیلدهایی را مشاهده یا تغییر دهد که نباید به آن‌ها دسترسی داشته باشد.

OWASP این مشکل را در نسخه 2023 با عنوان Broken Object Property Level Authorization یا BOPLA معرفی کرده است.

این آسیب‌پذیری معمولاً باعث افشای اطلاعات حساس، افزایش سطح دسترسی و تغییر غیرمجاز داده‌ها می‌شود.

BOPLA چیست؟

BOPLA زمانی رخ می‌دهد که سیستم کنترل مناسبی روی ویژگی‌ها (Properties) یا فیلدهای یک شیء نداشته باشد.

به عبارت ساده:

کاربر به رکورد دسترسی دارد، اما نباید همه فیلدهای آن را مشاهده یا ویرایش کند.

مثال ساده

فرض کنید API اطلاعات پروفایل کاربر را باز می‌گرداند:

{
  "id": 25,
  "name": "Ali",
  "email": "ali@example.com",
  "role": "admin",
  "salary": 10000,
  "is_super_admin": true
}

کاربر عادی فقط باید نام و ایمیل خود را مشاهده کند.

اما به دلیل ضعف طراحی API، اطلاعات حساس نیز نمایش داده می‌شوند.

نمونه افشای اطلاعات

درخواست:

GET /api/profile

پاسخ:

{
  "name": "Ali",
  "email": "ali@example.com",
  "salary": 10000,
  "role": "admin",
  "is_super_admin": true
}

اطلاعاتی مانند:

• سطح دسترسی
• حقوق
• تنظیمات مدیریتی

نباید برای کاربران عادی نمایش داده شوند.

Mass Assignment چیست؟

یکی از رایج‌ترین مصادیق BOPLA است.

نمونه درخواست:

{
  "name": "Ali",
  "email": "ali@example.com",
  "is_admin": true
}

اگر برنامه تمام فیلدها را بدون کنترل ذخیره کند، کاربر می‌تواند سطح دسترسی خود را افزایش دهد.

---

نمونه آسیب‌پذیر در Laravel

User::create($request->all());

یا

$user->update($request->all());

در این حالت هر فیلدی که کاربر ارسال کند ذخیره می‌شود.

نمونه ایمن

در مدل:

protected $fillable = [
    'name',
    'email'
];

یا

protected $guarded = [
    'role',
    'is_admin',
    'is_super_admin'
];

افشای داده‌های حساس

نمونه دیگری از BOPLA:

return User::find($id);

پاسخ:

{
  "name": "Ali",
  "email": "ali@example.com",
  "password": "$2y$10...",
  "remember_token": "..."
}

هرگز نباید چنین اطلاعاتی در پاسخ API نمایش داده شوند.

استفاده از API Resource در Laravel

بهترین روش استفاده از Resource است:

return new UserResource($user);

نمونه:

public function toArray($request)
{
    return [
        'id' => $this->id,
        'name' => $this->name,
        'email' => $this->email
    ];
}

اکنون فقط فیلدهای مجاز نمایش داده می‌شوند.

نشانه‌های وجود BOPLA

اگر موارد زیر وجود دارد باید بررسی امنیتی انجام شود:

• استفاده از request->all()
• استفاده از Model مستقیم در Response
• نبود Resource Layer
• نبود کنترل فیلدهای قابل ویرایش
• نمایش اطلاعات مدیریتی

روش‌های شناسایی

تست دستی

در Body درخواست فیلدهای جدید اضافه کنید:

{
  "is_admin": true
}

یا:

{
  "role": "admin"
}

اگر ذخیره شدند، آسیب‌پذیری وجود دارد.

بررسی پاسخ API

اطمینان حاصل کنید که:

• Password Hash
• API Keys
• Tokens
• نقش‌های مدیریتی

در خروجی نمایش داده نمی‌شوند.

بهترین روش‌های دفاع

استفاده از Allow List

به جای مشخص کردن موارد ممنوع، فقط فیلدهای مجاز را تعریف کنید.

استفاده از Resource Layer

هرگز مدل را مستقیماً بازنگردانید.

تفکیک DTOها

مدل پایگاه داده را مستقیماً به API متصل نکنید.

تست امنیتی خودکار

در CI/CD بررسی شود که فیلدهای حساس در خروجی وجود نداشته باشند.

چک‌لیست امنیتی BOPLA

• آیا از Resource استفاده شده است؟
• آیا request->all() حذف شده است؟
• آیا فیلدهای مدیریتی محافظت شده‌اند؟
• آیا Password و Token مخفی شده‌اند؟
• آیا فقط داده‌های ضروری نمایش داده می‌شوند؟

جمع‌بندی

Broken Object Property Level Authorization یکی از آسیب‌پذیری‌های مهم API است که معمولاً در اثر طراحی نامناسب مدل داده و کنترل ضعیف فیلدها ایجاد می‌شود. مهاجمان می‌توانند از این ضعف برای مشاهده اطلاعات حساس یا حتی افزایش سطح دسترسی خود استفاده کنند. استفاده از Resourceها، کنترل دقیق فیلدهای ورودی و اصل Least Privilege مهم‌ترین راهکارهای مقابله با این تهدید هستند.