آسیب‌پذیری IDOR چیست؟ چگونه از دسترسی غیرمجاز به اطلاعات کاربران جلوگیری کنیم؟

آسیب‌پذیری IDOR یا Insecure Direct Object Reference زمانی ایجاد می‌شود که یک سایت یا API براساس شناسه‌ای مانند شماره کاربر، سفارش، فایل یا تیکت به یک منبع دسترسی می‌دهد، اما بررسی نمی‌کند آیا کاربر فعلی واقعاً مجاز به مشاهده یا تغییر آن منبع است یا خیر. راهکار اصلی جلوگیری از IDOR، اجرای Authorization سمت سرور برای هر Object و هر عملیات است.

مقدمه؛ وقتی ورود امن است اما اطلاعات کاربران هنوز امن نیست

در بسیاری از پروژه‌های وب، بخش بزرگی از تمرکز امنیتی روی فرایند ورود کاربران قرار می‌گیرد. مدیر سایت رمزهای عبور قوی را اجباری می‌کند، Brute Force را محدود می‌کند، احراز هویت دومرحله‌ای یا 2FA فعال می‌شود، HTTPS روی سایت قرار می‌گیرد و حتی WAF نیز در جلوی سرور نصب می‌شود.

با وجود همه این اقدامات، هنوز ممکن است یک کاربر کاملاً قانونی پس از ورود به حساب خود بتواند به اطلاعات کاربران دیگر دسترسی پیدا کند.

علت چیست؟

مشکل همیشه در Authentication یا احراز هویت نیست. گاهی سیستم به‌درستی تشخیص می‌دهد کاربر چه کسی است، اما در مرحله بعد یعنی Authorization یا «مجوزدهی» شکست می‌خورد.

فرض کنید کاربر شماره 125 وارد حساب خودش شده و قصد دارد یکی از فاکتورهایش را مشاهده کند. سایت شناسه فاکتور را دریافت می‌کند، آن رکورد را از پایگاه داده پیدا می‌کند و اطلاعات را نمایش می‌دهد. در ظاهر همه‌چیز عادی است.

اما سؤال امنیتی مهم این است:

آیا سرور بررسی کرده که این فاکتور واقعاً متعلق به همین کاربر است؟

اگر پاسخ منفی باشد، احتمال ایجاد آسیب‌پذیری IDOR وجود دارد.

OWASP، IDOR را نوعی ضعف کنترل دسترسی می‌داند که در آن یک Object مانند حساب، سند، تیکت یا تراکنش از طریق Referenceهایی مانند ID، UUID، شماره حساب، Token یا Slug قابل شناسایی است، اما سیستم بررسی Authorization در سطح همان Object را انجام نمی‌دهد.

موضوع زمانی مهم‌تر می‌شود که بدانیم در OWASP Top 10:2025، دسته Broken Access Control همچنان در رتبه اول ریسک‌های امنیتی برنامه‌های وب قرار دارد و خود OWASP دسترسی یا ویرایش حساب فرد دیگر از طریق شناسه آن را به‌عنوان نمونه مشخص IDOR معرفی می‌کند.

بنابراین آسیب‌پذیری IDOR مسئله‌ای کوچک یا صرفاً مربوط به URL نیست. این ضعف مستقیماً به معماری کنترل دسترسی برنامه مربوط می‌شود و در شرایط جدی می‌تواند به افشای اطلاعات شخصی، مشاهده سفارش‌ها، دانلود فایل‌های خصوصی، تغییر داده‌های دیگران و حتی افزایش سطح دسترسی منجر شود.

در این مقاله رخنه‌کاو، IDOR را از دید کاملاً دفاعی بررسی می‌کنیم و می‌بینیم چگونه می‌توان از دسترسی غیرمجاز به اطلاعات کاربران جلوگیری کرد.

آسیب‌پذیری IDOR چیست؟

IDOR مخفف عبارت Insecure Direct Object Reference است که می‌توان آن را «ارجاع مستقیم ناامن به شیء» ترجمه کرد.

در برنامه‌های وب تقریباً همه‌چیز می‌تواند یک Object باشد؛ برای مثال:

• حساب کاربری
• سفارش
• فاکتور
• تراکنش
• تیکت پشتیبانی
• پیام
• فایل
• تصویر خصوصی
• سند
• اشتراک
• پروژه
• آدرس کاربر
• درخواست برداشت
• گزارش
• رکورد سازمانی
• API Resource

برنامه برای پیدا کردن این Objectها معمولاً از یک Reference استفاده می‌کند.

این Reference می‌تواند موارد مختلفی باشد:

• ID عددی
• UUID
• نام فایل
• Username
• Slug
• شماره حساب
• شماره سفارش
• Token
• شناسه تراکنش

وجود چنین شناسه‌ای کاملاً طبیعی است و به‌تنهایی آسیب‌پذیری محسوب نمی‌شود.

مشکل زمانی ایجاد می‌شود که Backend پس از دریافت شناسه فقط بپرسد:

«آیا Object با این شناسه وجود دارد؟»

در حالی که سؤال درست باید این باشد:

«آیا Object وجود دارد و آیا کاربر فعلی اجازه انجام این عملیات روی آن را دارد؟»

در حقیقت برای ایجاد یک سناریوی IDOR معمولاً سه جزء وجود دارد:

1. یک Object مانند سفارش یا سند؛
2. یک Reference برای اشاره به Object؛
3. نبود یا نقص Object-Level Authorization.

OWASP همین سه مؤلفه را به‌عنوان اجزای اصلی IDOR توضیح می‌دهد.

یک مثال ساده برای درک IDOR

یک فروشگاه اینترنتی را در نظر بگیرید.

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

Backend هنگام دریافت درخواست، فاکتور را براساس invoice_id پیدا می‌کند.

دو حالت ممکن است وجود داشته باشد.

حالت امن

سرور بررسی می‌کند:

• کاربر چه کسی است؟
• فاکتور موردنظر کدام است؟
• مالک فاکتور چه کسی است؟
• آیا نقش کاربر اجازه مشاهده آن را می‌دهد؟

اگر فاکتور متعلق به فرد دیگری باشد، درخواست رد می‌شود.

حالت ناامن

سرور فقط بررسی می‌کند:

• آیا فاکتوری با این ID وجود دارد؟

اگر پاسخ مثبت باشد، اطلاعات را برمی‌گرداند.

در چنین معماری‌ای، داشتن شناسه Object عملاً تبدیل به مجوز دسترسی شده است.

این همان مشکلی است که IDOR ایجاد می‌کند.

آیا وجود ID عددی در URL یعنی سایت آسیب‌پذیر است؟

خیر.

یکی از اشتباهات رایج در بحث آسیب‌پذیری IDOR این است که تصور کنیم هر URL حاوی شناسه عددی خطرناک است.

برای مثال:

/orders/7412

وجود عدد 7412 در URL به‌تنهایی هیچ چیز را ثابت نمی‌کند.

اگر Backend پیش از نمایش سفارش بررسی کند کاربر فعلی اجازه مشاهده Order شماره 7412 را دارد، حتی یک ID کاملاً ترتیبی نیز لزوماً باعث IDOR نمی‌شود.

در مقابل ممکن است برنامه از یک UUID بسیار طولانی و غیرقابل حدس استفاده کند، اما هیچ Authorization واقعی روی Object اجرا نکند.

در آن شرایط معماری همچنان ناقص است.

بنابراین:

Predictability شناسه یک مسئله است، Authorization مسئله‌ای مهم‌تر.

تفاوت Authentication و Authorization در آسیب‌پذیری IDOR

برای درک IDOR باید تفاوت Authentication و Authorization را کاملاً بدانیم.

Authentication چیست؟

Authentication یا احراز هویت پاسخ می‌دهد:

«شما چه کسی هستید؟»

نمونه ابزارهای Authentication:

• نام کاربری و رمز عبور
• OTP
• 2FA
• Passkey
• Security Key
• Session
• برخی مدل‌های Token Authentication

Authorization چیست؟

Authorization یا مجوزدهی پاسخ می‌دهد:

«شما مجاز به انجام چه کاری هستید؟»

برای مثال:

• آیا این کاربر اجازه مشاهده این سفارش را دارد؟
• آیا می‌تواند این فایل را دانلود کند؟
• آیا می‌تواند این Post را ویرایش کند؟
• آیا اجازه حذف این Ticket را دارد؟
• آیا می‌تواند اطلاعات Tenant دیگری را ببیند؟

یک سیستم ممکن است Authentication بسیار قوی داشته باشد ولی Authorization بسیار ضعیفی داشته باشد.

برای مثال:

کاربر با رمز قوی و 2FA وارد سایت می‌شود.

هویت او بدون مشکل مشخص شده است.

اما Backend اجازه می‌دهد هر Order موجودی را صرفاً براساس ID مشاهده کند.

در این سناریو 2FA هیچ مشکلی را حل نمی‌کند، زیرا مسئله این نیست که هویت کاربر ناشناخته است.

مسئله این است که سیستم نمی‌داند یا بررسی نمی‌کند این کاربر اجازه دسترسی به چه چیزی را دارد.

ارتباط IDOR با Broken Access Control

IDOR را باید یکی از شکل‌های Broken Access Control دانست.

Broken Access Control به شرایطی گفته می‌شود که سیاست‌های دسترسی برنامه به‌درستی اجرا نمی‌شوند و کاربر قادر است عملی خارج از محدوده مجاز خود انجام دهد.

در OWASP Top 10:2025، Broken Access Control همچنان A01 و در رتبه اول قرار دارد. OWASP از جمله نمونه‌های این دسته به تغییر URL یا پارامترها برای عبور از کنترل دسترسی، مشاهده یا ویرایش حساب سایر کاربران با شناسه آن‌ها، APIهای فاقد کنترل دسترسی و افزایش سطح دسترسی اشاره می‌کند.

Broken Access Control می‌تواند موارد زیر را شامل شود:

• IDOR
• دسترسی کاربر عادی به قابلیت مدیریتی
• دسترسی به Object دیگران
• دسترسی به URL محافظت‌شده
• تغییر Permission
• دسترسی به Endpoint فاقد Authorization
• Vertical Privilege Escalation
• Horizontal Privilege Escalation
• Force Browsing
• دسترسی غیرمجاز به فایل خصوصی

بنابراین:

هر IDOR نوعی Broken Access Control است، اما هر Broken Access Control الزاماً IDOR نیست.

تفاوت IDOR و BOLA چیست؟

در امنیت API اصطلاح دیگری به نام BOLA بسیار رایج است.

BOLA مخفف:

Broken Object Level Authorization

است.

از نظر مفهومی، BOLA و IDOR در بسیاری از سناریوها به یک ریشه مشترک اشاره دارند: سیستم Object را از طریق یک شناسه پیدا می‌کند، اما بررسی نمی‌کند User مجاز به عملیات روی همان Object است یا خیر.

OWASP در API Security Top 10:2023، BOLA را در رتبه API1 قرار داده است و تأکید می‌کند هر API Endpoint که یک Object ID دریافت کرده و عملی روی آن انجام می‌دهد باید Object-Level Authorization را اجرا کند.

IDOR اصطلاحی قدیمی‌تر و شناخته‌شده‌تر در امنیت وب است، در حالی که BOLA بیشتر در معماری API مطرح می‌شود.

برای توسعه‌دهنده، مهم‌تر از نام آسیب‌پذیری این سؤال است:

آیا Server برای هر Object و هر Action مجوز User را بررسی می‌کند؟

آسیب‌پذیری IDOR چگونه ایجاد می‌شود؟

در بسیاری از پروژه‌ها IDOR از اعتماد بیش از حد Backend به Client ایجاد می‌شود.

Client می‌تواند موارد مختلفی باشد:

• مرورگر
• JavaScript Frontend
• اپلیکیشن موبایل
• Desktop Application
• API Client

Server نباید فرض کند چون Frontend فقط Objectهای مجاز را نشان می‌دهد، User نمی‌تواند Reference دیگری ارسال کند.

هر داده‌ای که Client ارسال می‌کند باید بالقوه غیرقابل اعتماد در نظر گرفته شود.

الگوی طراحی ناامن

معماری ناامن معمولاً چنین روندی دارد:

User Request ↓ دریافت Object ID ↓ جست‌وجوی Object در Database ↓ بازگرداندن Object

در این جریان هیچ مرحله Authorization وجود ندارد.

معماری مناسب‌تر

User Request ↓ Authentication ↓ تشخیص User Identity ↓ دریافت Object Reference ↓ تعیین Scope ↓ Object-Level Authorization ↓ Business Rules ↓ Data Access ↓ Response

تفاوت اصلی دقیقاً در همین مرحله Object-Level Authorization است.

آسیب‌پذیری IDOR در چه بخش‌هایی بیشتر دیده می‌شود؟

تقریباً هر بخشی که یک Resource خصوصی دارد می‌تواند در معرض IDOR باشد.

پروفایل کاربران

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

• ایمیل
• شماره تماس
• آدرس
• تنظیمات
• اطلاعات حساب

باید براساس Policy مشخص در دسترس باشند.

سفارش‌ها

در فروشگاه‌های اینترنتی Order معمولاً حاوی اطلاعات حساسی مانند:

• نام مشتری
• شماره تماس
• آدرس
• محصولات خریداری‌شده
• مبلغ
• وضعیت پرداخت

است.

به همین دلیل Order ID باید تحت Authorization قرار بگیرد.

فاکتورها

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

دانستن Invoice ID نباید به معنی مجوز مشاهده Invoice باشد.

تیکت‌های پشتیبانی

Ticketها معمولاً حاوی اطلاعات مهم هستند:

• توضیحات مشکلات حساب
• اطلاعات دامنه
• Screenshot
• فایل پیوست
• اطلاعات تماس

افشای Ticketهای دیگران می‌تواند پیامد امنیتی قابل توجهی داشته باشد.

فایل‌ها

IDOR فقط روی Database Record اتفاق نمی‌افتد.

File ID، Attachment ID یا حتی Filename نیز Object Reference هستند.

فایل خصوصی نباید صرفاً به دلیل دانستن URL قابل دریافت باشد.

پیام‌ها

در سامانه‌های پیام‌رسان، Support System یا Workspaceهای تیمی، Message ID نیز باید در Scope مجاز بررسی شود.

API

APIها یکی از مهم‌ترین نقاطی هستند که Object-Level Authorization باید در آن‌ها جدی گرفته شود.

OWASP تأکید می‌کند Endpointهایی که شناسه Object را از Client دریافت می‌کنند باید بررسی کنند User فعلی اجازه Action درخواست‌شده روی Object موردنظر را دارد.

انواع آسیب‌پذیری IDOR براساس تأثیر

Read-Based IDOR

در این مدل، User اطلاعات Object دیگری را مشاهده می‌کند.

پیامد احتمالی:

• افشای اطلاعات شخصی
• افشای اطلاعات مالی
• مشاهده اسناد
• مشاهده پیام‌ها
• مشاهده سفارش‌ها

Write-Based IDOR

User می‌تواند Object دیگران را تغییر دهد.

این حالت Integrity داده را نیز تهدید می‌کند.

Delete-Based IDOR

در صورت نبود کنترل مجوز در عملیات حذف، ممکن است امکان حذف Object خارج از Scope ایجاد شود.

Download IDOR

فایل‌ها یا Attachmentهای خصوصی بدون Authorization مناسب در دسترس قرار می‌گیرند.

Action-Based IDOR

گاهی Object فقط مشاهده یا ویرایش نمی‌شود، بلکه عملی روی آن انجام می‌شود.

برای مثال:

• تأیید
• Cancel
• Archive
• Publish
• Share

هر Action نیازمند Permission مستقل است.

Horizontal Privilege Escalation و IDOR

بسیاری از موارد IDOR باعث Horizontal Privilege Escalation می‌شوند.

یعنی:

User A → به Object مربوط به User B دسترسی پیدا می‌کند.

هر دو ممکن است نقش Customer داشته باشند و از نظر Role در یک سطح باشند.

اما یک Customer نباید به اطلاعات Customer دیگری دسترسی داشته باشد.

به همین دلیل صرفاً Role-Based Access Control همیشه کافی نیست.

Vertical Privilege Escalation و IDOR

در برخی طراحی‌ها، IDOR ممکن است باعث رسیدن به Object یا عملیاتی شود که در سطح بالاتری قرار دارد.

برای مثال یک Object مدیریتی ممکن است به دلیل Authorization ناقص در دسترس User عادی قرار گیرد.

در چنین شرایطی IDOR می‌تواند با Vertical Privilege Escalation هم‌پوشانی پیدا کند.

با این حال این دو اصطلاح یکسان نیستند.

چرا IDهای ترتیبی می‌توانند خطر را افزایش دهند؟

IDهای عددی مانند:

1001 1002 1003 1004

قابل پیش‌بینی هستند.

این ویژگی می‌تواند کشف Objectهای دیگر را ساده‌تر کند.

همچنین ممکن است اطلاعاتی درباره:

• ترتیب ایجاد رکوردها
• تعداد تقریبی کاربران
• تعداد سفارش‌ها
• حجم فعالیت سیستم

آشکار کند.

با این حال باید تأکید کرد:

قابل پیش‌بینی بودن ID علت اصلی IDOR نیست.

علت اصلی نبود Authorization است.

آیا UUID آسیب‌پذیری IDOR را رفع می‌کند؟

خیر.

استفاده از UUID می‌تواند بسیار مفید باشد، اما نباید جای Authorization را بگیرد.

OWASP استفاده از شناسه‌های تصادفی و غیرقابل پیش‌بینی مانند GUID/UUID را به‌عنوان یکی از لایه‌های دفاعی پیشنهاد می‌کند، ولی همزمان تأکید دارد مکانیزم Authorization باید روی تمام توابعی که با Record کار می‌کنند اجرا شود.

بنابراین:

UUID = Defense in Depth

Authorization = کنترل اصلی امنیتی

فرض کنید UUID یک فایل از طریق:

• Log
• Browser History
• Screenshot
• ایمیل
• Referer
• Link Sharing

افشا شود.

اگر Server Authorization نداشته باشد، پیچیده بودن UUID دیگر کمکی نمی‌کند.

آیا Hash کردن ID راهکار مناسبی است؟

Hash یا Encode کردن ID نیز به‌تنهایی کافی نیست.

اگر منطق برنامه چنین باشد:

«هر کس Reference را دارد، مجاز است»

تبدیل Reference عددی به Hash فقط حدس‌زدن آن را دشوارتر می‌کند.

مدل امنیتی همچنان اشتباه است.

اصل مناسب این است:

Possession of Identifier does not equal Authorization.

داشتن شناسه نباید معادل داشتن مجوز باشد.

مهم‌ترین اصل جلوگیری از IDOR؛ Authorization سمت سرور

کنترل دسترسی باید در محیطی اجرا شود که User نتواند آن را تغییر دهد.

OWASP در توصیه‌های Broken Access Control تأکید می‌کند Access Control زمانی مؤثر است که در کد قابل اعتماد سمت Server یا Serverless API اجرا شود.

به همین دلیل موارد زیر Security Boundary واقعی نیستند:

• مخفی کردن Button
• غیرفعال کردن Input
• Hidden Field
• شرط JavaScript
• مخفی کردن Route در Frontend
• حذف لینک از Menu

این موارد برای UX مفید هستند، اما امنیت را Backend باید enforce کند.

اصل Deny by Default

یکی از مهم‌ترین اصول طراحی کنترل دسترسی:

Deny by Default

است.

یعنی اگر Policy صراحتاً اجازه نداده است، درخواست رد شود.

به‌جای:

«همه مجازند مگر اینکه ممنوع شوند»

از مدل زیر استفاده کنید:

«هیچ‌کس مجاز نیست مگر اینکه Permission مشخص داشته باشد.»

OWASP نیز Deny by Default را به‌عنوان یکی از اصول اصلی پیشگیری از Broken Access Control توصیه می‌کند.

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

اصل Least Privilege در جلوگیری از IDOR

Least Privilege یا اصل حداقل دسترسی می‌گوید هر User یا Process فقط باید حداقل Permission لازم برای انجام وظیفه خودش را دریافت کند.

NIST این اصل را محدود کردن دسترسی کاربران یا Processها به حداقل منابع و مجوزهای لازم برای انجام وظیفه تعریف می‌کند.

در کنترل IDOR می‌توان Least Privilege را در سطوح مختلف اعمال کرد:

• User
• Role
• Object
• Action
• Property
• Tenant
• Service

برای مثال یک Support Agent ممکن است مجاز به مشاهده یک Ticket باشد ولی نباید تمام اطلاعات مالی مشتری را مشاهده کند.

Query را از ابتدا به Scope کاربر محدود کنید

یکی از قوی‌ترین الگوهای دفاعی این است که Object در محدوده مجاز User جست‌وجو شود.

به‌صورت مفهومی به‌جای:

Find Object where id = requested_id

به مدل زیر نزدیک شوید:

Find Object where id = requested_id AND owner = current_user

در SaaS:

Find Object where id = requested_id AND tenant = current_tenant

مزیت این طراحی آن است که Ownership بخشی از Data Access می‌شود.

در نتیجه احتمال فراموش شدن Authorization کاهش می‌یابد.

هر Action باید Authorization مستقل داشته باشد

یک خطای رایج این است که توسعه‌دهنده بررسی می‌کند User اجازه مشاهده Object را دارد و سپس تصور می‌کند تمام عملیات دیگر نیز مجاز هستند.

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

برای مثال:

Read = مجاز Update = غیرمجاز Delete = غیرمجاز Export = غیرمجاز

به همین دلیل عملیات زیر باید مستقل بررسی شوند:

• GET
• POST
• PUT
• PATCH
• DELETE
• Download
• Export
• Share
• Approve

OWASP نیز APIهای دارای POST، PUT و DELETE بدون کنترل دسترسی را از نمونه‌های Broken Access Control معرفی می‌کند.

RBAC برای جلوگیری از IDOR

RBAC مخفف:

Role-Based Access Control

است.

در این مدل Permission براساس Role تعیین می‌شود.

مثال:

• Customer
• Editor
• Support Agent
• Manager
• Administrator

RBAC برای بسیاری از برنامه‌ها مفید است، اما به‌تنهایی مشکل Object Ownership را حل نمی‌کند.

فرض کنید User A و User B هر دو Customer هستند.

Role هر دو یکسان است.

اما User A نباید Order متعلق به B را مشاهده کند.

بنابراین Policy بهتر است علاوه بر Role، Ownership را نیز بررسی کند.

ABAC چیست؟

ABAC یعنی:

Attribute-Based Access Control

در این مدل تصمیم دسترسی براساس Attributeهای مختلف گرفته می‌شود.

برای مثال:

• Role
• Department
• Owner ID
• Tenant
• Object Status
• Region
• Security Level

ABAC برای سیستم‌های پیچیده‌تر انعطاف بیشتری دارد.

ReBAC چیست؟

ReBAC یا Relationship-Based Access Control براساس رابطه User و Resource تصمیم می‌گیرد.

برای مثال:

User عضو Project است.

User Owner سند است.

User Manager تیمی است که Document به آن تعلق دارد.

این مدل در برنامه‌های Collaborative و SaaS کاربرد زیادی دارد.

معماری پیشنهادی برای جلوگیری از آسیب‌پذیری IDOR

یک جریان مناسب می‌تواند چنین باشد:

Request ↓ Authentication ↓ Identity Context ↓ Object Reference ↓ Scope Resolution ↓ Object-Level Authorization ↓ Business Rule Validation ↓ Data Access ↓ Property Filtering ↓ Response ↓ Security Logging

هر مرحله هدف جداگانه‌ای دارد.

Authentication

مشخص می‌کند چه کسی Request داده است.

Identity Context

اطلاعات قابل اعتماد User و Tenant تعیین می‌شود.

Scope Resolution

مشخص می‌شود User اصولاً در چه محدوده‌ای می‌تواند Object جست‌وجو کند.

Object-Level Authorization

Permission دقیق روی Object بررسی می‌شود.

Business Rule Validation

محدودیت‌های تجاری بررسی می‌شوند.

Property Filtering

فقط فیلدهایی برگردانده می‌شوند که User مجاز به مشاهده آن‌هاست.

Logging

تصمیم‌های امنیتی مهم ثبت می‌شوند.

کنترل دسترسی در سطح Property

گاهی User به خود Object دسترسی دارد، اما نباید همه Propertyهای آن را ببیند.

فرض کنید API یک User Object دارد:

• display_name
• avatar
• email
• phone
• role
• internal_flags
• security_metadata

ممکن است فقط دو فیلد اول عمومی باشند.

اگر Backend تمام Model داخلی را Serialize کند، اطلاعات اضافی افشا می‌شوند.

OWASP API Security Top 10 این مسئله را تحت عنوان Broken Object Property Level Authorization بررسی می‌کند و نسبت به APIهایی که تمام Propertyهای Object را بدون کنترل مناسب برمی‌گردانند هشدار می‌دهد.

بنابراین باید دو سؤال پرسیده شود:

1. آیا User به Object دسترسی دارد؟
2. اگر دارد، به کدام Propertyهای Object دسترسی دارد؟

آسیب‌پذیری IDOR در سیستم‌های Multi-Tenant

در SaaSهای چندسازمانی، IDOR می‌تواند بسیار خطرناک‌تر باشد.

مثلاً:

Tenant A نباید اطلاعات Tenant B

را مشاهده کند.

در این معماری، کنترل صرف user_id کافی نیست.

معمولاً باید Contextهای زیر نیز لحاظ شوند:

• Tenant ID
• Organization ID
• Workspace ID
• Project ID

یک Query اشتباه بدون Tenant Scope ممکن است به Cross-Tenant Data Exposure منجر شود.

چک‌لیست Multi-Tenant

• Tenant از Context معتبر استخراج شود.
• Client نتواند Tenant خود را آزادانه تعیین کند.
• Queryها Tenant Scope داشته باشند.
• Cache براساس Tenant تفکیک شود.
• Background Jobها Tenant-aware باشند.
• Exportها Scope داشته باشند.
• Object Storage نیز Tenant Isolation داشته باشد.
• Testهای Cross-Tenant نوشته شوند.

IDOR در REST API

در REST API معمولاً Object ID در بخش‌های مختلف Request قرار می‌گیرد:

• Path
• Query Parameter
• Request Body
• Header

صرف مکان قرارگیری ID اهمیتی ندارد.

هر Endpoint که Object را براساس Reference پیدا می‌کند باید Authorization مناسب داشته باشد.

OWASP BOLA را یکی از مهم‌ترین ریسک‌های API می‌داند و می‌گوید همه توابعی که از ID برای دسترسی به Data Source استفاده می‌کنند باید Object-Level Authorization داشته باشند.

IDOR در GraphQL

GraphQL نیز از خطر Object-Level Authorization مصون نیست.

Resolverها ممکن است Object را براساس ID یا رابطه‌ای دیگر پیدا کنند.

Authorization باید در معماری GraphQL نیز اجرا شود.

نکته مهم این است که Security نباید صرفاً به این دلیل که Schema بعضی فیلدها را در UI نمایش نمی‌دهد، امن فرض شود.

Resolver و Data Access Layer باید Scope واقعی User را enforce کنند.

فایل‌های خصوصی و IDOR

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

فرض کنید فایل‌ها در مسیر عمومی قرار گرفته‌اند و فقط نام آن‌ها پیچیده است.

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

برای فایل حساس بهتر است:

• Authorization قبل از دانلود انجام شود.
• دسترسی براساس User و Object بررسی شود.
• فایل عمومی و خصوصی از هم تفکیک شوند.
• Signed URL در صورت نیاز کوتاه‌عمر باشد.
• Metadata نیز کنترل شود.

Signed URL آیا IDOR را حل می‌کند؟

Signed URL ابزار مفیدی است، اما صدور آن نیز باید Authorization داشته باشد.

سیستم ابتدا باید بررسی کند:

• چه Userی لینک را درخواست کرده؟
• به چه Fileی؟
• آیا اجازه دانلود دارد؟
• لینک تا چه زمانی معتبر باشد؟

اگر User بتواند برای هر File ID دلخواه Signed URL تولید کند، مشکل Object-Level Authorization همچنان باقی است.

Cache و خطر افشای اطلاعات کاربران

گاهی Application Authorization درست است اما Cache باعث Data Leak می‌شود.

برای مثال Response خصوصی یک User در Cache ذخیره شده و سپس برای User دیگری ارائه می‌شود.

در Endpointهای حساس موارد زیر را بررسی کنید:

• Cache Key شامل User Context باشد.
• Cache Key شامل Tenant باشد.
• CDN اطلاعات خصوصی را عمومی Cache نکند.
• Reverse Proxy Policy درست باشد.
• Cache Invalidation درست انجام شود.
• Headerهای Cache مناسب باشند.

Authorization فقط Database Query نیست؛ تمام مسیر انتقال Data باید Boundaryهای امنیتی را حفظ کند.

آسیب‌پذیری IDOR در وردپرس

در سایت‌های WordPress، IDOR معمولاً می‌تواند در بخش‌هایی مانند موارد زیر ایجاد شود:

• افزونه اختصاصی
• REST API سفارشی
• AJAX Handler
• Theme Function
• سیستم تیکت
• سیستم دانلود
• پنل کاربری
• افزونه فروشگاهی سفارشی

مسئله مهم این است که Login بودن User به‌تنهایی مجوز دسترسی محسوب نمی‌شود.

استفاده از current_user_can در WordPress

WordPress برای بررسی Capability کاربر تابع:

current_user_can()

را فراهم می‌کند.

مستندات رسمی WordPress توضیح می‌دهد که این تابع می‌تواند Capability کاربر فعلی را بررسی کند و برای Meta Capabilityها، Object ID نیز در تصمیم دخیل شود؛ برای مثال بررسی Permission روی یک Post خاص. مستندات همچنین توصیه می‌کنند به‌جای تکیه مستقیم بر Role، Capability بررسی شود.

از نظر معماری، سؤال مناسب این نیست:

«آیا این User Editor است؟»

بلکه:

«آیا این User اجازه انجام این Action روی این Object را دارد؟»

permission_callback در WordPress REST API

برای REST Routeهای سفارشی، WordPress سازوکار مهمی به نام:

permission_callback

دارد.

مستندات WordPress می‌گوید Permissions Callback پیش از Callback اصلی بررسی می‌کند User اجازه اجرای Action را دارد یا خیر و توصیه می‌کند در صورت امکان به‌جای صرفاً Login بودن، از Capabilityهایی مانند current_user_can() استفاده شود.

از WordPress 5.5 نیز اگر permission_callback هنگام ثبت Route ارائه نشود، WordPress هشدار _doing_it_wrong ایجاد می‌کند.

برای Endpoint خصوصی باید Permission Callback براساس Policy واقعی نوشته شود.

صرف وجود آن کافی نیست؛ منطق داخل آن نیز باید درست باشد.

Nonce در WordPress جلوی IDOR را نمی‌گیرد

این نکته برای توسعه‌دهندگان WordPress بسیار مهم است.

Nonce ابزار مفیدی برای کاهش ریسک CSRF است، اما Authorization نیست.

مستندات رسمی WordPress صریحاً اعلام می‌کند Nonce نباید برای Authentication، Authorization یا Access Control مورد اتکا قرار گیرد و توابع حساس باید با Permissionهایی مانند current_user_can() محافظت شوند.

بنابراین وجود:

wp_verify_nonce()

یا:

check_ajax_referer()

به معنی امن بودن Endpoint از IDOR نیست.

یک Endpoint ممکن است Nonce کاملاً معتبر داشته باشد ولی User هنوز مجوز Object موردنظر را نداشته باشد.

تفاوت IDOR و CSRF

IDOR و CSRF دو ضعف متفاوت هستند.

در CSRF مسئله این است که مرورگر User احراز هویت‌شده ناخواسته Requestی را ارسال کند.

در IDOR مسئله این است که Server مجوز User روی Object را درست بررسی نمی‌کند.

Nonce می‌تواند بخشی از دفاع CSRF باشد.

Object-Level Authorization دفاع اصلی IDOR است.

هر دو ممکن است همزمان نیاز باشند.

تفاوت IDOR و SQL Injection

در SQL Injection، ورودی User می‌تواند ساختار Query را تحت تأثیر قرار دهد.

در IDOR ممکن است Query کاملاً Parameterized و از نظر Injection امن باشد، اما Authorization ناقص باشد.

یعنی Database دقیقاً همان Object درخواست‌شده را پیدا می‌کند؛ مشکل این است که User نباید اجازه دسترسی به آن Object را داشته باشد.

Prepared Statement مشکل SQL Injection را حل می‌کند، نه IDOR را.

تفاوت IDOR و XSS

XSS به اجرای محتوای ناامن در Browser مربوط است.

IDOR به مجوز دسترسی Server-side Object مربوط می‌شود.

Sanitization، Escaping و CSP برای XSS مهم هستند، اما جای Authorization را نمی‌گیرند.

آیا WAF می‌تواند جلوی آسیب‌پذیری IDOR را بگیرد؟

WAF ابزار مهمی در Defense in Depth است، اما درمان اصلی IDOR نیست.

بسیاری از Requestهای IDOR از دید HTTP کاملاً معتبر هستند:

• User وارد شده است.
• Session معتبر است.
• Method معتبر است.
• Parameter نوع صحیح دارد.
• هیچ Payload مخربی ارسال نمی‌شود.

تنها مسئله این است که Object متعلق به User نیست.

WAF معمولاً اطلاعات کامل Business Logic و Ownership Database را ندارد.

بنابراین تصمیم اصلی باید در Application Layer گرفته شود.

WAF ممکن است رفتارهای غیرعادی را شناسایی یا محدود کند، اما نباید جایگزین Authorization شود.

آیا Rate Limiting از IDOR جلوگیری می‌کند؟

Rate Limiting نیز کنترل مکمل است.

اگر Authorization وجود نداشته باشد، Rate Limit صرفاً سرعت دسترسی غیرمجاز را کاهش می‌دهد.

OWASP در Broken Access Control استفاده از Rate Limiting را برای کاهش اثر ابزارهای خودکار پیشنهاد می‌کند، ولی کنترل اصلی همچنان Authorization است.

ترتیب منطقی:

Authorization صحیح + Rate Limiting + Monitoring

آیا 2FA از آسیب‌پذیری IDOR جلوگیری می‌کند؟

خیر.

2FA برای Authentication است.

IDOR در Authorization رخ می‌دهد.

User می‌تواند کاملاً قانونی وارد حساب خودش شده باشد و همچنان به دلیل نقص Backend، Object فرد دیگری را مشاهده کند.

بنابراین:

2FA = آیا واقعاً خودت هستی؟

Authorization = آیا اجازه انجام این کار را داری؟

هر دو برای امنیت مهم هستند، ولی وظایف متفاوت دارند.

Logging و Monitoring برای تشخیص سوءاستفاده از IDOR

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

OWASP پیشنهاد می‌کند شکست‌های Access Control ثبت شوند و در موارد مناسب برای تکرار رفتار مشکوک Alert ایجاد شود.

یک Log مفید می‌تواند شامل موارد زیر باشد:

• User ID
• Tenant ID
• Object Type
• Object Reference
• Action
• Allow یا Deny
• Endpoint
• Timestamp
• Correlation ID

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

• Password
• Secret
• Token کامل
• Credential

بدون ضرورت وارد Log شوند.

رفتارهای قابل بررسی

• تعداد زیاد Access Denied
• تلاش روی Objectهای متعدد
• Cross-Tenant Access Denied
• دانلود غیرعادی فایل‌های زیاد
• Exportهای حجیم
• فعالیت مدیریتی غیرمعمول

چگونه IDOR را به‌صورت دفاعی تست کنیم؟

تست امنیتی باید فقط روی سامانه‌ای انجام شود که مالک آن هستید یا مجوز صریح آزمایش آن را دارید.

هدف تست IDOR این است که مشخص شود Boundary دسترسی بین کاربران به‌درستی enforce شده است.

مرحله اول: Objectها را فهرست کنید

برای مثال:

• User
• Order
• Invoice
• Ticket
• File
• Message
• Project
• Transaction

مرحله دوم: Owner مشخص کنید

برای هر Object تعیین کنید چه کسی Owner است.

مرحله سوم: Actionها را مشخص کنید

برای هر Object مشخص کنید چه کسی می‌تواند:

• Read
• Update
• Delete
• Download
• Export

انجام دهد.

مرحله چهارم: حداقل دو حساب آزمایشی داشته باشید

User A و User B هر کدام Objectهای مستقل داشته باشند.

سپس Test Suite بررسی کند:

User A → Object A = مجاز User A → Object B = رد

OWASP نیز استفاده از تست‌های Authorization و بررسی دسترسی کاربران به Objectهای خارج از Scope را توصیه می‌کند.

ماتریس کنترل دسترسی

قبل از پیاده‌سازی می‌توان Authorization Matrix تهیه کرد.

<table> <thead> <tr> <th>عملیات</th> <th>مالک</th> <th>کاربر دیگر</th> <th>پشتیبانی</th> <th>مدیر</th> </tr> </thead> <tbody> <tr> <td>مشاهده</td> <td>مجاز</td> <td>غیرمجاز</td> <td>طبق Policy</td> <td>طبق Policy</td> </tr> <tr> <td>ویرایش</td> <td>طبق Policy</td> <td>غیرمجاز</td> <td>محدود</td> <td>طبق Policy</td> </tr> <tr> <td>حذف</td> <td>محدود</td> <td>غیرمجاز</td> <td>غیرمجاز</td> <td>طبق Policy</td> </tr> <tr> <td>دانلود</td> <td>مجاز</td> <td>غیرمجاز</td> <td>طبق Policy</td> <td>طبق Policy</td> </tr> <tr> <td>Export</td> <td>طبق Policy</td> <td>غیرمجاز</td> <td>طبق Policy</td> <td>طبق Policy</td> </tr> </tbody> </table>

این جدول باید براساس Business Logic واقعی سایت طراحی شود.

تست خودکار Authorization

یکی از مؤثرترین اقدامات دفاعی، تبدیل Policyهای Authorization به Automated Test است.

Positive Test

User مجاز باید بتواند Action را انجام دهد.

Negative Test

User غیرمجاز باید با پاسخ مناسب رد شود.

Cross-User Test

User A نباید Object متعلق به User B را دریافت کند.

Cross-Tenant Test

Tenant A نباید به Object متعلق به Tenant B دسترسی داشته باشد.

Role Boundary Test

Role پایین‌تر نباید Action مخصوص Role بالاتر را اجرا کند.

Property-Level Test

فیلدهای حساس نباید در Response کاربران غیرمجاز وجود داشته باشند.

چرا Regression Test اهمیت دارد؟

ممکن است امروز Authorization کاملاً درست باشد ولی پس از:

• Refactor
• تغییر ORM
• اضافه شدن Endpoint
• تغییر Role
• تغییر Business Logic
• اضافه شدن Mobile API

یکی از کنترل‌ها حذف شود.

Regression Test جلوی بازگشت آسیب‌پذیری را می‌گیرد.

OWASP در راهنمای BOLA نیز نوشتن تست‌هایی برای ارزیابی مکانیزم Authorization و جلوگیری از Deployment در صورت شکست آن‌ها را توصیه می‌کند.

پاسخ مناسب Server به دسترسی غیرمجاز

دو Status Code رایج در این زمینه:

403 Forbidden

و در برخی معماری‌ها:

404 Not Found

هستند.

403 نشان می‌دهد Resource شناخته شده اما User مجوز ندارد.

برخی سیستم‌ها برای جلوگیری از افشای وجود Object خصوصی از 404 استفاده می‌کنند.

انتخاب دقیق به Threat Model بستگی دارد.

مهم‌تر از Code این است که اطلاعات Object در Response افشا نشود.

از افشای اطلاعات در پیام خطا جلوگیری کنید

Error Response نباید اطلاعات غیرضروری داخلی را نمایش دهد.

برای مثال:

• Stack Trace
• Database Query
• Table Name
• Internal Path
• Owner Information
• Secret
• Token
• جزئیات داخلی Policy

Errorهای دقیق‌تر می‌توانند در Log داخلی ثبت شوند، اما Client فقط اطلاعات ضروری را دریافت کند.

اشتباهات رایج در جلوگیری از آسیب‌پذیری IDOR

اشتباه اول: فقط بررسی کنیم User Login است

Login بودن فقط Authentication را ثابت می‌کند.

User واردشده همچنان ممکن است به Object دیگری مجاز نباشد.

اشتباه دوم: UUID را جای Authorization بگذاریم

UUID مفید است، اما کنترل اصلی نیست.

اشتباه سوم: ID را Hash کنیم و مسئله را حل‌شده بدانیم

Hash فقط Reference را کمتر قابل پیش‌بینی می‌کند.

اشتباه چهارم: Button را مخفی کنیم

UI یک Security Boundary نیست.

اشتباه پنجم: Hidden Input را امن فرض کنیم

Hidden Field نیز از سمت Client ارسال می‌شود و باید غیرقابل اعتماد فرض شود.

اشتباه ششم: Validation را با Authorization اشتباه بگیریم

اینکه Order ID عددی است:

Validation

است.

اینکه User اجازه دیدن همان Order را دارد:

Authorization

است.

اشتباه هفتم: در WordPress فقط Nonce بررسی کنیم

Nonce Authorization نیست. مستندات رسمی WordPress نیز این موضوع را صریحاً بیان می‌کنند.

اشتباه هشتم: فقط Role را بررسی کنیم

دو User با Role یکسان الزاماً نباید به Objectهای هم دسترسی داشته باشند.

اشتباه نهم: فقط GET را امن کنیم

PATCH، PUT، DELETE، Export و Download نیز باید Authorization داشته باشند.

اشتباه دهم: Access Control را در Controllerها پراکنده کنیم

هرچه Logic مجوزدهی پراکنده‌تر باشد، احتمال فراموش شدن آن بیشتر است.

بهتر است مکانیزم Authorization:

• متمرکز
• قابل استفاده مجدد
• قابل تست
• قابل Audit

باشد.

اشتباه یازدهم: به WAF تکیه کنیم

WAF معمولاً Ownership Object را نمی‌شناسد.

اشتباه دوازدهم: Admin را بدون محدودیت رها کنیم

حتی Roleهای قدرتمند نیز باید مطابق نیاز واقعی Permission داشته باشند.

اصل Least Privilege همچنان اهمیت دارد.

طراحی Authorization Policy مناسب

یک مدل ساده و مفید برای تصمیم دسترسی:

Subject + Action + Object + Context = Decision

Subject

چه کسی درخواست می‌دهد؟

Action

چه کاری می‌خواهد انجام دهد؟

Object

روی چه Resourceی؟

Context

در چه Tenant، Role، وضعیت یا شرایطی؟

Decision

Allow یا Deny؟

برای مثال:

User 17 می‌خواهد Invoice 92 را در Tenant 3 مشاهده کند.

Policy باید تمام اجزای لازم را بررسی کند.

Code Review برای کشف مشکلات IDOR

در Code Review فقط به Injection یا Sanitization نگاه نکنید.

برای هر Endpoint حساس این سؤال‌ها را مطرح کنید:

• Identity از کجا می‌آید؟
• Object چگونه Resolve می‌شود؟
• Owner کجا بررسی می‌شود؟
• Tenant کجا بررسی می‌شود؟
• Permission قبل از Data Access بررسی می‌شود؟
• چه کسی اجازه Update دارد؟
• آیا Delete Policy متفاوت است؟
• Response چه Propertyهایی دارد؟
• تست منفی وجود دارد؟

این پرسش‌ها احتمال کشف Broken Access Control را افزایش می‌دهند.

Secure SDLC و جلوگیری از IDOR قبل از تولید

بهترین زمان اصلاح IDOR بعد از Incident نیست.

Authorization باید از مرحله طراحی وارد Secure SDLC شود.

طراحی

مشخص کنید:

• Object حساس چیست؟
• Owner کیست؟
• Roleها چیست؟
• Tenant Boundary چیست؟
• چه Actionهایی وجود دارد؟

توسعه

از Authorization Component مشترک استفاده کنید.

Code Review

Ownership و Permission بررسی شوند.

تست

Cross-User و Cross-Tenant Test وجود داشته باشند.

Deployment

Cache، Proxy و Storage نیز Boundaryها را حفظ کنند.

Monitoring

Access Denied و فعالیت‌های غیرعادی پایش شوند.

چه زمانی IDOR شدت بالایی دارد؟

Severity آسیب‌پذیری به شرایط بستگی دارد.

حساسیت داده

دسترسی به اطلاعات مالی با یک Object عمومی یکسان نیست.

نوع عملیات

Read با Delete اثر یکسانی ندارد.

تعداد Objectهای در معرض

آیا فقط یک Object یا کل Dataset در معرض است؟

قابلیت گسترش

آیا مشکل می‌تواند تعداد زیادی User را تحت تأثیر قرار دهد؟

Cross-Tenant بودن

افشای اطلاعات یک سازمان برای سازمان دیگر معمولاً ریسک بالایی دارد.

امکان افزایش سطح دسترسی

آیا تغییر Object می‌تواند Permission بیشتری ایجاد کند؟

اگر IDOR در سایت پیدا کردیم چه کار کنیم؟

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

1. Endpoint آسیب‌پذیر را محدود کنید

در صورت امکان Route یا Feature را موقتاً محدود کنید.

2. Authorization را اصلاح کنید

Patch اصلی باید در Server-side Authorization باشد.

3. Endpointهای مشابه را بررسی کنید

اگر یک Route مشکل دارد، احتمال وجود Pattern مشابه در نقاط دیگر زیاد است.

4. Logها را بررسی کنید

مشخص کنید آیا دسترسی غیرعادی رخ داده است یا خیر.

5. دامنه داده‌های در معرض را مشخص کنید

چه Objectهایی و چه Userهایی تحت تأثیر بوده‌اند؟

6. Regression Test بنویسید

Patch بدون Test ممکن است دوباره شکسته شود.

7. Multi-Tenant Boundary را بررسی کنید

اگر SaaS است، Cross-Tenant Access در اولویت بالا قرار دارد.

8. Incident Response را فعال کنید

اگر اطلاعات واقعی کاربران در معرض بوده است، فرایند Incident Response و الزامات سازمانی و قانونی را بررسی کنید.

چک‌لیست توسعه‌دهندگان برای جلوگیری از IDOR

قبل از انتشار Feature جدید این موارد را بررسی کنید:

• Object حساس مشخص شده است.
• Owner مشخص است.
• User Identity از Context معتبر گرفته می‌شود.
• Client تعیین‌کننده هویت نیست.
• Query به User Scope محدود شده است.
• Query در SaaS به Tenant محدود شده است.
• Authorization سمت Server اجرا می‌شود.
• Deny by Default رعایت شده است.
• Least Privilege رعایت شده است.
• Read Permission بررسی می‌شود.
• Update Permission بررسی می‌شود.
• Delete Permission بررسی می‌شود.
• Export Permission بررسی می‌شود.
• Download Permission بررسی می‌شود.
• UI به‌عنوان Security Boundary استفاده نشده است.
• UUID فقط Defense in Depth است.
• Propertyهای Response حداقلی هستند.
• فایل خصوصی کنترل دسترسی دارد.
• Signed URL مجوز و Expiry دارد.
• Cache User-aware یا Tenant-aware است.
• Access Denied ثبت می‌شود.
• Cross-User Test وجود دارد.
• Cross-Tenant Test وجود دارد.
• Authorization Regression Test وجود دارد.
• Admin Permissionها بیش از حد گسترده نیستند.
• Endpointهای Legacy نیز بررسی شده‌اند.
• Mobile API همان Policy لازم را دارد.

چک‌لیست امنیت IDOR برای WordPress

در سایت WordPress موارد زیر اهمیت ویژه دارند:

• REST Routeهای سفارشی بررسی شوند.
• permission_callback وجود داشته باشد.
• Private Route با __return_true باز نشده باشد.
• Capability مناسب بررسی شود.
• در صورت نیاز Object ID وارد Permission Check شود.
• current_user_can() به‌درستی استفاده شود.
• Nonce جای Authorization را نگرفته باشد.
• AJAX Handlerهای خصوصی بررسی شوند.
• Pluginهای اختصاصی Code Review شوند.
• Download Handlerها Authorization داشته باشند.
• WooCommerce Custom Endpointها بررسی شوند.
• User Meta حساس بدون Permission برگردانده نشود.

مقایسه IDOR با آسیب‌پذیری‌های رایج دیگر

<table> <thead> <tr> <th>آسیب‌پذیری</th> <th>مشکل اصلی</th> <th>راهکار اصلی</th> </tr> </thead> <tbody> <tr> <td>IDOR / BOLA</td> <td>نبود Authorization روی Object</td> <td>Object-Level Authorization</td> </tr> <tr> <td>Broken Authentication</td> <td>ضعف در تشخیص هویت</td> <td>Authentication امن و 2FA</td> </tr> <tr> <td>CSRF</td> <td>ارسال Request ناخواسته</td> <td>Anti-CSRF Controls</td> </tr> <tr> <td>XSS</td> <td>اجرای محتوای ناامن در Browser</td> <td>Output Encoding، Sanitization و CSP</td> </tr> <tr> <td>SQL Injection</td> <td>دستکاری Query</td> <td>Parameterized Queries</td> </tr> <tr> <td>Brute Force</td> <td>حدس Credential</td> <td>Rate Limiting، MFA و Detection</td> </tr> </tbody> </table>

سؤالات متداول درباره آسیب‌پذیری IDOR

آسیب‌پذیری IDOR چیست؟

IDOR نوعی Broken Access Control است که زمانی رخ می‌دهد که برنامه Object را براساس یک Reference مانند ID یا UUID پیدا می‌کند اما بررسی نمی‌کند User درخواست‌کننده اجازه دسترسی به همان Object را دارد یا خیر.

آیا IDOR فقط در IDهای عددی اتفاق می‌افتد؟

خیر.

ID، UUID، Filename، Slug، Username، Account Number و Token همگی ممکن است Object Reference باشند.

آیا UUID جلوی IDOR را می‌گیرد؟

خیر.

UUID کشف Object را دشوارتر می‌کند اما جای Authorization را نمی‌گیرد.

آیا IDOR فقط باعث افشای اطلاعات می‌شود؟

خیر.

در بعضی سیستم‌ها می‌تواند باعث:

• مشاهده
• تغییر
• حذف
• دانلود
• اجرای Action

غیرمجاز شود.

تفاوت IDOR و BOLA چیست؟

BOLA اصطلاح رایج‌تری در API Security است و روی Broken Object Level Authorization تمرکز دارد. بسیاری از سناریوهای IDOR و BOLA از نظر فنی ریشه یکسانی دارند.

آیا WAF جلوی IDOR را می‌گیرد؟

نه به‌عنوان راهکار اصلی.

WAF می‌تواند لایه دفاعی مکمل باشد، اما Authorization باید در Application اجرا شود.

آیا 2FA مشکل IDOR را حل می‌کند؟

خیر.

2FA Authentication را تقویت می‌کند ولی IDOR مربوط به Authorization است.

آیا مخفی کردن ID در Frontend کافی است؟

خیر.

Client تحت کنترل کامل Server نیست.

Backend باید Permission را مستقل بررسی کند.

آیا Nonce در WordPress برای جلوگیری از IDOR کافی است؟

خیر.

WordPress صریحاً اعلام کرده Nonce نباید برای Authorization یا Access Control استفاده شود و Permissionهایی مانند current_user_can() باید بررسی شوند.

آیا IDOR فقط در API وجود دارد؟

خیر.

IDOR می‌تواند در:

• سایت
• REST API
• GraphQL
• Mobile Backend
• AJAX
• Download Endpoint

ایجاد شود.

مهم‌ترین روش جلوگیری از آسیب‌پذیری IDOR چیست؟

مهم‌ترین اقدام، اجرای Object-Level Authorization سمت Server برای هر Request و هر Action است.

آیا Rate Limiting کافی است؟

خیر.

Rate Limiting فقط کنترل مکمل است و نمی‌تواند جای Authorization را بگیرد.

آیا استفاده از Role برای جلوگیری از IDOR کافی است؟

همیشه نه.

Role مشخص می‌کند User چه سطح کلی Permission دارد، ولی Ownership یا رابطه او با Object نیز ممکن است نیاز به بررسی داشته باشد.

آیا فایل‌های خصوصی هم می‌توانند IDOR داشته باشند؟

بله.

Filename، File ID و Attachment ID هم Object Reference هستند و Download Endpoint باید Authorization داشته باشد.

چگونه بفهمیم سایت WordPress ما در برابر IDOR مقاوم است؟

REST API، AJAX Handlerها، Pluginهای سفارشی، سیستم دانلود و Endpointهای حساب کاربری باید از نظر Capability، Ownership و Object-Level Authorization بررسی شوند. تست با چند حساب دارای Scope متفاوت نیز اهمیت زیادی دارد.

جمع‌بندی؛ برای جلوگیری از IDOR به شناسه اعتماد نکنید

آسیب‌پذیری IDOR یکی از مهم‌ترین انواع Broken Access Control است و زمانی ایجاد می‌شود که Backend یک Object مانند حساب کاربری، سفارش، فایل، فاکتور یا تیکت را براساس شناسه پیدا می‌کند، اما بررسی نمی‌کند User فعلی مجوز دسترسی به همان Object را دارد یا خیر.

اصل مهم این است که داشتن ID نباید به معنی داشتن Permission باشد.

IDهای عددی و ترتیبی می‌توانند کشف Objectها را آسان‌تر کنند و استفاده از UUID یا Reference تصادفی می‌تواند یک لایه Defense in Depth مفید باشد؛ اما این تغییر به‌تنهایی آسیب‌پذیری IDOR را رفع نمی‌کند.

کنترل اصلی باید Server-side Authorization باشد.

سیستم باید برای هر Request مشخص کند:

• User چه کسی است؟
• چه Actionی می‌خواهد؟
• Object چیست؟
• Owner چه کسی است؟
• Tenant کدام است؟
• Policy چه اجازه‌ای می‌دهد؟

اصولی مانند Deny by Default و Least Privilege احتمال ایجاد دسترسی‌های ناخواسته را کاهش می‌دهند. NIST نیز Least Privilege را محدود کردن مجوز هر Entity به حداقل منابع و دسترسی‌های لازم تعریف می‌کند.

در APIها نیز Object-Level Authorization باید بخشی از هر Endpointی باشد که با Object ID کار می‌کند. OWASP BOLA را یکی از اصلی‌ترین ریسک‌های API معرفی کرده و توصیه می‌کند مکانیزم Authorization برای هر عملیات روی Record اعمال شود.

در WordPress نیز نباید Nonce را با Authorization اشتباه گرفت. Nonce برای اهدافی مانند کاهش ریسک CSRF مفید است، اما مستندات رسمی WordPress تأکید می‌کنند برای کنترل مجوز باید از Capabilityها و مکانیزم‌هایی مانند current_user_can() و permission_callback استفاده شود.

در نهایت، اگر بخواهیم مهم‌ترین قانون امنیتی این مقاله را در یک جمله خلاصه کنیم:

سرور هرگز نباید صرفاً به این دلیل که یک کاربر شناسه Object را می‌داند یا در اختیار دارد، اجازه مشاهده، ویرایش، حذف یا دانلود آن Object را صادر کند.