Broken Access Control چیست؟ بررسی آسیب‌پذیری کنترل دسترسی و روش‌های جلوگیری

Broken Access Control یا «نقص کنترل دسترسی» زمانی رخ می‌دهد که یک وب‌سایت یا API نتواند به‌درستی بررسی کند هر کاربر به چه اطلاعات، منابع و عملیاتی اجازه دسترسی دارد. در نتیجه ممکن است کاربر عادی بتواند اطلاعات کاربر دیگری را مشاهده کند، داده‌ای را تغییر دهد، وارد بخش مدیریتی شود یا عملیاتی خارج از سطح دسترسی خود انجام دهد. مهم‌ترین راهکارهای پیشگیری شامل Deny by Default، Least Privilege، بررسی Authorization در تمام درخواست‌ها و اجرای کنترل دسترسی در سمت سرور است.

Broken Access Control در OWASP Top 10:2025 همچنان رتبه اول خطرهای امنیتی برنامه‌های وب را در اختیار دارد. در داده‌های بررسی‌شده توسط OWASP، این دسته شامل ۴۰ CWE بوده و بیش از ۱.۸ میلیون رخداد ثبت‌شده داشته است. OWASP توضیح می‌دهد که نقص کنترل دسترسی می‌تواند به افشای غیرمجاز اطلاعات، تغییر یا حذف داده و اجرای عملیات تجاری خارج از محدوده مجاز کاربر منجر شود.

اهمیت این آسیب‌پذیری از یک واقعیت ساده ناشی می‌شود: بسیاری از سیستم‌ها کاربران را به‌درستی شناسایی می‌کنند، اما پس از ورود به حساب بررسی نمی‌کنند که آن کاربر دقیقاً اجازه انجام چه کاری را دارد.

ممکن است کاربری کاملاً Legitimate باشد، Password صحیح داشته باشد و حتی با احراز هویت دو مرحله‌ای وارد سایت شده باشد، اما این موضوع به معنی اجازه دسترسی او به تمام اطلاعات سیستم نیست.

به همین دلیل باید میان دو مفهوم مهم تفاوت قائل شویم:

Authentication و Authorization.

Authentication مشخص می‌کند «شما چه کسی هستید؟»

Authorization مشخص می‌کند «شما اجازه انجام چه کاری را دارید؟»

OWASP نیز Authorization را فرایند بررسی این موضوع تعریف می‌کند که آیا یک Action یا Service برای Entity درخواست‌کننده مجاز است یا خیر و تأکید دارد که Authentication و Authorization دو مفهوم مستقل هستند.

در این مقاله از رخنه‌کاو بررسی می‌کنیم Broken Access Control چیست، چه انواعی دارد، IDOR چه ارتباطی با آن دارد، Horizontal و Vertical Privilege Escalation چه هستند، APIها چگونه درگیر این آسیب‌پذیری می‌شوند و مهم‌تر از همه چگونه می‌توان یک معماری کنترل دسترسی امن طراحی کرد.

Broken Access Control چیست؟

Access Control مجموعه قوانینی است که مشخص می‌کند:

• چه کسی می‌تواند یک Resource را مشاهده کند؛
• چه کسی اجازه تغییر آن را دارد؛
• چه کسی اجازه حذف آن را دارد؛
• چه کسی می‌تواند یک Function را اجرا کند؛
• و یک کاربر در چه شرایطی اجازه انجام یک عملیات را دارد.

برای مثال در یک فروشگاه اینترنتی ممکن است سه سطح کاربری وجود داشته باشد:

Customer
Shop Manager
Administrator

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

Shop Manager ممکن است اجازه مدیریت سفارش‌ها را داشته باشد.

Administrator نیز دسترسی‌های مدیریتی بیشتری خواهد داشت.

اگر یک Customer بتواند صرفاً با تغییر یک URL یا Parameter اطلاعات سفارش Customer دیگری را مشاهده کند، Access Control دچار مشکل شده است.

اگر همان Customer بتواند به Function مخصوص Administrator دسترسی پیدا کند، مشکل شدیدتری وجود دارد.

بنابراین Broken Access Control یک Vulnerability منفرد با یک شکل مشخص نیست؛ بلکه یک خانواده بزرگ از مشکلات Authorization است.

چرا Broken Access Control رتبه اول OWASP Top 10 است؟

در OWASP Top 10:2025، Broken Access Control همچنان A01 یعنی اولین دسته امنیتی باقی مانده است.

OWASP در داده‌های مربوط به نسخه 2025 گزارش می‌کند که این دسته ۴۰ CWE را پوشش می‌دهد و در داده‌های ارائه‌شده بیش از ۱,۸۳۹,۰۰۰ مورد رخداد داشته است. همچنین مواردی مانند Exposure of Sensitive Information، CSRF و در نسخه 2025 حتی SSRF نیز در این دسته‌بندی دیده می‌شوند.

دلیل اصلی خطرناک بودن Broken Access Control این است که بسیاری از این مشکلات مستقیماً به داده یا Function حساس منتهی می‌شوند.

در بعضی آسیب‌پذیری‌ها مهاجم ابتدا باید چند مرحله Exploit انجام دهد.

اما یک Authorization Failure ممکن است مستقیماً باعث شود کاربر:

• Invoice شخص دیگری را ببیند؛
• سفارش دیگری را تغییر دهد؛
• فایل خصوصی را دانلود کند؛
• تنظیمات حساب دیگری را مشاهده کند؛
• Endpoint مدیریتی را اجرا کند؛
• یا اطلاعات متعلق به Tenant دیگری را دریافت کند.

از طرف دیگر، طراحی Access Control معمولاً به Business Logic وابسته است.

یک WAF عمومی همیشه نمی‌تواند تشخیص دهد که User 125 اجازه مشاهده Invoice 892 را دارد یا خیر.

این موضوع را خود Application باید بداند.

به همین دلیل بسیاری از مشکلات Authorization صرفاً با نصب یک Plugin امنیتی یا Firewall برطرف نمی‌شوند.

تفاوت Authentication و Authorization چیست؟

این دو اصطلاح دائماً با یکدیگر اشتباه گرفته می‌شوند.

Authentication

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

«این کاربر چه کسی است؟»

مثلاً:

Username
+
Password
+
2FA

پس از موفقیت Authentication، Application می‌فهمد:

Current User = User 125

Authorization

اکنون کاربر درخواست می‌دهد:

مشاهده Invoice 892

Application باید سؤال دیگری بپرسد:

آیا User 125 اجازه مشاهده Invoice 892 را دارد؟

این همان Authorization است.

اگر سیستم فقط Login بودن کاربر را بررسی کند:

if logged_in:
    allow

اما Ownership یا Permission را بررسی نکند، ممکن است Broken Access Control ایجاد شود.

OWASP نیز تأکید می‌کند که Authenticated بودن کاربر به معنی مجاز بودن او برای تمام Resourceها و Actionهای سیستم نیست.

یک سیستم کنترل دسترسی سالم چگونه تصمیم می‌گیرد؟

یک Access Control Decision معمولاً چند جزء دارد.

Subject

کسی که درخواست را ارسال کرده است.

مثلاً:

User 125

Resource یا Object

چیزی که کاربر می‌خواهد به آن دسترسی پیدا کند.

مثلاً:

Invoice 892

Action

عملیات موردنظر:

Read
Update
Delete
Export
Approve

Context

شرایط اضافی.

مثلاً:

• Tenant
• Department
• Time
• Device
• Location
• Account Status

تصمیم نهایی ممکن است چیزی شبیه این باشد:

User 125
می‌تواند
Invoice 892
را مشاهده کند
اگر مالک آن Invoice باشد.

این Policy باید در Server اجرا شود.

Horizontal Privilege Escalation چیست؟

Horizontal Privilege Escalation یکی از رایج‌ترین شکل‌های Broken Access Control است.

در این وضعیت مهاجم همان سطح Role خودش را حفظ می‌کند، اما به Resource متعلق به User دیگری دسترسی پیدا می‌کند.

مثلاً:

User A → Invoice A
User B → Invoice B

رفتار صحیح:

User A → Invoice A ✅
User A → Invoice B ❌

اگر سیستم حالت دوم را نیز Allow کند، Horizontal Access Control شکسته شده است.

نمونه‌های Resource:

• Ticket
• Order
• Invoice
• Message
• Profile
• Address
• Document
• API Object
• Uploaded File

OWASP نیز Horizontal Privilege Elevation را یکی از ضعف‌های متداول Authorization معرفی می‌کند.

Vertical Privilege Escalation چیست؟

در Vertical Privilege Escalation کاربر تلاش می‌کند سطح دسترسی بالاتری به دست آورد.

مثلاً:

Customer
↓
Administrator

یا:

Editor
↓
Site Administrator

اگر یک User عادی بتواند Function مدیریتی را اجرا کند، Vertical Access Control شکسته شده است.

مثلاً ممکن است UI دکمه زیر را نمایش ندهد:

Delete User

اما Endpoint آن همچنان برای User عادی قابل اجرا باشد.

پنهان کردن Button یک Access Control نیست.

Server باید Permission را بررسی کند.

Context-Dependent Access Control چیست؟

گاهی Access فقط به User یا Role وابسته نیست.

مثلاً کاربر اجازه Cancel کردن Order را دارد:

فقط زمانی که:

Order Status = Pending

اگر Order ارسال شده باشد:

Order Status = Shipped

دیگر Cancel نباید ممکن باشد.

اگر Application فقط بررسی کند کاربر Owner سفارش است ولی State را بررسی نکند، Business Logic Access Control ممکن است شکسته شود.

این نوع Policy در:

• Banking
• Workflow
• E-commerce
• Approval Systems
• SaaS

اهمیت بسیار زیادی دارد.

IDOR چه ارتباطی با Broken Access Control دارد؟

IDOR مخفف:

Insecure Direct Object Reference

است.

IDOR یکی از شناخته‌شده‌ترین زیرمجموعه‌های Broken Access Control است.

فرض کنیم سایت Objectها را با ID مشخص کند:

/orders/812

کاربر Owner سفارش 812 است.

حال درخواست Resource دیگری مطرح می‌شود:

/orders/813

مسئله امنیتی زمانی رخ می‌دهد که Application فقط ID را دریافت کند و Object را Load کند، بدون اینکه بررسی کند Current User واقعاً اجازه مشاهده آن را دارد.

OWASP توصیه می‌کند Access Control برای هر Object بررسی شود و استفاده از Identifierهای پیچیده مانند UUID را فقط یک Defense in Depth بداند، نه جایگزین Authorization.

آیا استفاده از UUID مشکل IDOR را حل می‌کند؟

خیر.

فرض کنید به‌جای:

/orders/813

از UUID استفاده کنیم.

حدس زدن Resource بسیار سخت‌تر خواهد شد.

این اقدام مفید است.

اما اگر URL یک Object خصوصی به هر روش دیگری افشا شود و Application Ownership را بررسی نکند، Vulnerability همچنان وجود دارد.

OWASP صراحتاً می‌گوید حتی با Identifierهای پیچیده نیز Access Control Check ضروری است.

بنابراین:

UUID ≠ Authorization

UUID فقط Predictability را کاهش می‌دهد.

Missing Function Level Authorization چیست؟

گاهی Resource Object مشکل ندارد، بلکه کل Function بدون Authorization مناسب در دسترس قرار گرفته است.

مثلاً Endpoint:

/admin/delete-user

باید فقط برای Administrator اجرا شود.

اگر Application فقط لینک آن را از Menu کاربران عادی حذف کند، اما Server Role را بررسی نکند، Function همچنان آسیب‌پذیر است.

یک User ممکن است از طریق Request مستقیم Endpoint را فراخوانی کند.

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

Forced Browsing چیست؟

Forced Browsing زمانی مطرح می‌شود که Resource یا Page در UI دیده نمی‌شود، اما با دانستن یا حدس زدن مسیر مستقیم قابل دسترسی است.

برای مثال ممکن است سایت Navigation مربوط به Admin را فقط برای Admin نمایش دهد.

اما مسیر:

/admin/reports

در سمت Server Authorization نداشته باشد.

مخفی کردن Link امنیت ایجاد نمی‌کند.

OWASP Force Browsing به صفحات Authenticated یا Privileged را نیز در فهرست Broken Access Control قرار می‌دهد.

کنترل دسترسی فقط در Frontend یک اشتباه جدی است

یکی از مهم‌ترین اصول:

هر چیزی در Browser تحت کنترل User است.

JavaScript را می‌توان تغییر داد.

Request را می‌توان مستقیماً ارسال کرد.

HTML را می‌توان تغییر داد.

Button مخفی را می‌توان نادیده گرفت.

بنابراین کدی مثل:

اگر Role = admin
دکمه Delete را نشان بده

فقط برای User Experience مفید است.

امنیت واقعی باید هنگام Request بررسی شود.

OWASP تأکید می‌کند Access Control باید در Trusted Server-Side Code، Gateway یا Serverless Function اجرا شود و نباید به Client-Side Logic متکی باشد.

Broken Access Control در REST API

APIها یکی از مهم‌ترین نقاط بروز مشکلات Authorization هستند.

فرض کنیم API چنین Endpointهایی دارد:

GET /api/orders/{id}
PUT /api/orders/{id}
DELETE /api/orders/{id}

ممکن است Developer Access Control را برای GET پیاده‌سازی کند اما فراموش کند PUT یا DELETE همان Object را نیز بررسی کند.

OWASP توصیه می‌کند REST Serviceهای غیرعمومی در هر Endpoint Access Control داشته باشند.

همچنین Access Control باید Operation-specific باشد.

داشتن Read Permission الزاماً به معنی داشتن:

Update Permission
Delete Permission
Export Permission

نیست.

Broken Object Level Authorization یا BOLA چیست؟

در امنیت API اصطلاح BOLA یا:

Broken Object Level Authorization

بسیار نزدیک به IDOR است.

Application یک Object Identifier دریافت می‌کند اما بررسی نمی‌کند Caller به همان Object دسترسی دارد یا خیر.

برای مثال:

GET /api/documents/{document_id}

نباید فقط وجود Document بررسی شود.

باید Relation کاربر با Document نیز بررسی شود.

مدل صحیح:

Document exists?
AND
Current user is allowed?

است.

Broken Access Control در سیستم‌های Multi-Tenant

این مسئله در SaaS بسیار حساس‌تر است.

فرض کنید یک Platform دارای چند Company باشد:

Tenant A
Tenant B
Tenant C

هر Tenant اطلاعات خودش را دارد.

حتی اگر دو User Role یکسان داشته باشند:

Tenant A Admin
Tenant B Admin

نباید بتوانند Resourceهای یکدیگر را مشاهده کنند.

بنابراین Query نباید فقط بگوید:

Find invoice by id

بلکه Scope باید Tenant را هم شامل شود:

Find invoice
where tenant = current tenant
and id = requested id

Cross-Tenant Access یکی از خطرناک‌ترین شکل‌های Broken Access Control در SaaS است.

Role-Based Access Control یا RBAC چیست؟

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

مثلاً:

Customer:
- View own orders

Editor:
- Edit articles

Administrator:
- Manage users

RBAC ساده، قابل فهم و بسیار رایج است.

برای بسیاری از سایت‌ها نیز کاملاً مناسب است.

اما مشکل زمانی ایجاد می‌شود که Access Control پیچیده‌تر از چند Role ساده باشد.

ABAC چیست؟

ABAC مخفف:

Attribute-Based Access Control

است.

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

• User Role
• Tenant
• Department
• Device
• Time
• Resource Classification
• Location
• Object Owner

مثلاً:

User.department == Document.department
AND
User.clearance >= Document.classification

OWASP اشاره می‌کند ABAC می‌تواند Fine-Grained Access Control دقیق‌تری نسبت به RBAC فراهم کند و در بسیاری از Applicationهای پیچیده انتخاب مناسب‌تری باشد.

ReBAC چیست؟

ReBAC یا:

Relationship-Based Access Control

براساس Relation میان Entityها تصمیم می‌گیرد.

برای مثال:

User owns document

یا:

User is member of project

یا:

User manages department

این مدل برای Applicationهایی مثل:

• Social Networks
• Collaboration Platforms
• Project Management
• SaaS

بسیار مفید است.

OWASP نیز ABAC و ReBAC را برای بسیاری از Applicationها نسبت به RBAC ساده انعطاف‌پذیرتر می‌داند، مخصوصاً جایی که Object-Level Access اهمیت دارد.

اصل Least Privilege چیست؟

Least Privilege یعنی هر User، Service و Component فقط حداقل Permission لازم را دریافت کند.

مثلاً اگر یک Editor فقط نیاز دارد:

Create Article
Edit Article

نباید Permission:

Manage Users
Install Plugins
Change Security Settings

داشته باشد.

Least Privilege باید هم Vertical و هم Horizontal باشد.

OWASP تأکید می‌کند Privilege باید متناسب با نیاز واقعی Entity تعیین شود و Permissionهای کاربران نیز در طول زمان برای جلوگیری از Privilege Creep بازبینی شوند.

Privilege Creep چیست؟

Privilege Creep زمانی اتفاق می‌افتد که Permissionهای User به مرور زمان زیاد می‌شوند ولی Permissionهای قدیمی حذف نمی‌شوند.

مثلاً کارمند ابتدا Support بوده است.

سپس به Marketing رفته.

بعد Manager شده است.

اگر Permissionهای تمام Roleهای قبلی باقی بمانند، User ممکن است بیش از نیاز دسترسی داشته باشد.

بنابراین Access Review دوره‌ای ضروری است.

Deny by Default چیست؟

Deny by Default یکی از مهم‌ترین اصول Access Control است.

مدل اشتباه:

اگر Rule خاصی برای Block پیدا نکردی:
Allow

مدل امن:

اگر Permission به‌صورت صریح تأیید نشد:
Deny

OWASP صریحاً توصیه می‌کند Applicationها Access را به‌صورت پیش‌فرض Deny کنند و هر Permission باید دلیل مشخص برای Grant شدن داشته باشد.

این اصل احتمال Errorهایی را که هنگام اضافه شدن Feature جدید رخ می‌دهند کاهش می‌دهد.

Authorization باید روی هر Request بررسی شود

فرض کنید User هنگام ورود Permission داشته است.

آیا می‌توان Permission را فقط همان لحظه بررسی کرد؟

خیر.

ممکن است:

• Role کاربر تغییر کرده باشد؛
• Membership حذف شده باشد؛
• Resource Owner تغییر کرده باشد؛
• Account Disable شده باشد؛
• Object State تغییر کرده باشد.

OWASP توصیه می‌کند Permission برای هر Request بررسی شود، فارغ از اینکه درخواست از AJAX، Browser، API یا منبع دیگری آمده باشد. حتی فراموش شدن Access Control روی یک Endpoint می‌تواند محرمانگی یا یکپارچگی Resource را از بین ببرد.

Access Control را در یک نقطه مرکزی طراحی کنید

یکی از علل Broken Access Control این است که Authorization Logic در ده‌ها Controller پراکنده باشد.

مثلاً Developer در هر Function چیزی شبیه این بنویسد:

if user.role ...

مشکل این روش:

• بعضی Endpointها فراموش می‌شوند؛
• Policyها با هم ناسازگار می‌شوند؛
• تغییر Role سخت می‌شود؛
• Testing پیچیده می‌شود.

بهتر است Framework یا Architecture دارای:

• Middleware
• Policy
• Guard
• Authorization Service

مرکزی باشد.

OWASP نیز توصیه می‌کند Access Control Mechanism یک‌بار طراحی و در سراسر Application Reuse شود.

Object Ownership را مستقیماً Enforcement کنید

یکی از اصول بسیار مهم:

Resource را ابتدا از Scope مجاز User پیدا کنید.

مدل پرریسک:

Document = find_by_id(request.id)
بعد بررسی User

مدل بهتر:

Document = current_user.allowed_documents.find(request.id)

OWASP در راهنمای IDOR نیز پیشنهاد می‌کند Query روی Datasetهایی انجام شود که User اجازه دسترسی به آن‌ها دارد.

این الگو احتمال فراموش شدن Ownership Check را کاهش می‌دهد.

Static Fileها هم Access Control می‌خواهند

گاهی Application Permission بسیار قوی دارد، اما فایل حساس در URL عمومی قرار گرفته است.

مثلاً:

/uploads/contracts/...

اگر Contract خصوصی است، Random بودن URL کنترل دسترسی محسوب نمی‌شود.

Static Resource نیز ممکن است نیازمند Authorization باشد.

OWASP تأکید می‌کند Static Resourceها نیز باید در Access Control Policy قرار بگیرند و Cloud Storage مانند Object Storage نیز باید متناسب با حساسیت Data تنظیم شود.

فایل خصوصی را چگونه ارائه کنیم؟

برای Resource خصوصی، مدل بهتر می‌تواند چنین باشد:

User
↓
Download Request
↓
Authentication
↓
Authorization
↓
Resource Mapping
↓
Controlled Download

در Cloud Storage می‌توان در بعضی معماری‌ها از:

Short-lived Signed URL

استفاده کرد.

اما Application ابتدا باید Authorization را انجام دهد.

CORS چه ارتباطی با Broken Access Control دارد؟

CORS یا Cross-Origin Resource Sharing مشخص می‌کند Browser اجازه دهد Scriptهای Originهای دیگر Response یک Resource را بخوانند یا خیر.

اگر CORS بیش از حد باز تنظیم شود، ممکن است Originهای غیرمجاز به API دسترسی پیدا کنند.

OWASP نیز CORS Misconfiguration را یکی از نمونه‌های Broken Access Control معرفی می‌کند.

MDN توصیه می‌کند Access-Control-Allow-Origin فقط برای حداقل Originهای لازم تنظیم شود و در Credentialed Requestها نباید Originهای ورودی بدون کنترل Reflect شوند.

آیا Access-Control-Allow-Origin: * همیشه خطرناک است؟

خیر.

برای یک Public API یا Resource عمومی بدون Credential ممکن است کاملاً منطقی باشد.

مشکل زمانی است که Resource خصوصی است یا Credentials وارد جریان می‌شوند.

Security Setting باید متناسب با Data Classification باشد.

هدف این نیست:

همیشه CORS را ببند

بلکه:

فقط Originهایی را Allow کن که واقعاً نیاز دارند.

JWT و Broken Access Control

JWT معمولاً Claimsهایی مانند:

sub
role
scope
aud
iss
exp

دارد.

Application ممکن است براساس آن‌ها Access Decision بگیرد.

مشکل زمانی رخ می‌دهد که:

• Signature به‌درستی Validate نشود؛
• Expiration نادیده گرفته شود؛
• Audience بررسی نشود؛
• Role اشتباه Trust شود؛
• Token قدیمی پس از Permission Change معتبر بماند.

OWASP توصیه می‌کند JWT Integrity محافظت شود و Claims مهم از جمله iss و aud توسط Consumer بررسی شوند.

JWT یک Container است.

وجود JWT به معنی Authorization امن نیست.

Session و تغییر Permission

فرض کنید یک User Administrator بوده است.

سپس Administrator Permission او حذف می‌شود.

اگر Session یا Token قدیمی ساعت‌ها همچنان Admin Permission داشته باشد، Revocation مشکل پیدا کرده است.

برای Tokenهای Stateless باید Lifetime محدود و Strategy مناسب برای Refresh و Revocation در نظر گرفته شود.

OWASP نیز توصیه می‌کند Sessionهای Stateful پس از Logout سمت Server Invalid شوند و JWTهای Stateless کوتاه‌عمر باشند.

Rate Limit چه ارتباطی با Access Control دارد؟

Rate Limiting به‌تنهایی Authorization نیست.

اما بخشی از Defense in Depth است.

اگر Object IDها قابل Query باشند، Automation می‌تواند تعداد بسیار زیادی Request تولید کند.

OWASP در بخش Broken Access Control توصیه می‌کند API و Controllerها Rate Limit داشته باشند تا آسیب ناشی از ابزارهای Automated کاهش یابد.

Directory Listing را غیرفعال کنید

اگر Directory Listing فعال باشد، User ممکن است لیست فایل‌هایی را مشاهده کند که اصلاً قرار نبوده Discover شوند.

همچنین فایل‌های زیر نباید داخل Web Root باقی بمانند:

.git
backup.zip
database.sql
old-site/

OWASP در راهکارهای Broken Access Control توصیه می‌کند Directory Listing غیرفعال شود و Metadata و Backup Fileها در Web Root قرار نگیرند.

Broken Access Control در وردپرس

در WordPress مفاهیم Access Control عمدتاً با:

• Roles
• Capabilities
• Ownership
• Nonce
• Authentication

مدیریت می‌شوند.

یکی از اشتباهات Plugin Developerها این است که فقط Login بودن User را بررسی کنند.

مثلاً:

is_user_logged_in()

اما Function نیازمند Permission مدیریتی باشد.

Login بودن کافی نیست.

باید Capability متناسب بررسی شود.

مثلاً Conceptual:

current_user_can(required_capability)

نوع Capability به Function موردنظر بستگی دارد.

Role و Capability در وردپرس چه تفاوتی دارند؟

Role مجموعه‌ای از Capabilityهاست.

مثلاً Administrator یک Role است.

اما در Code معمولاً بهتر است به‌جای سؤال:

آیا User Administrator است؟

بپرسیم:

آیا User این Capability مشخص را دارد؟

این مدل Flexibleتر است.

Pluginها ممکن است Roleهای Custom ایجاد کنند و Capabilityها تغییر کنند.

AJAX و REST API وردپرس هم باید Authorization داشته باشند

یکی از اشتباهات مهم:

UI صفحه Admin Permission دارد ولی:

• AJAX Action
• REST Route

بدون Permission Check مناسب طراحی شده است.

هر Request باید مستقل Authorization شود.

صرف اینکه Endpoint از یک Admin Page فراخوانی می‌شود امنیت ایجاد نمی‌کند.

این دقیقاً با توصیه OWASP درباره بررسی Permission روی تمام Requestها هم‌راستا است.

WordPress Nonce جای Authorization را نمی‌گیرد

Nonce می‌تواند در برابر برخی Requestهای ناخواسته مانند CSRF نقش داشته باشد.

اما:

Valid Nonce

به معنی:

User Authorized

نیست.

برای Action حساس معمولاً باید:

Authentication
+
Capability Check
+
Nonce/CSRF Protection

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

چرا Broken Access Control معمولاً سخت پیدا می‌شود؟

Scanner می‌تواند بسیاری از مشکلات Technical را تشخیص دهد.

اما Authorization به Business Context وابسته است.

Scanner از کجا بداند:

آیا Support Agent باید Invoice را Refund کند؟

یا:

آیا Project Manager اجازه حذف Project متعلق به Department دیگر را دارد؟

به همین دلیل Manual Security Testing و Threat Modeling اهمیت دارند.

تست دفاعی Broken Access Control چگونه انجام می‌شود؟

هدف تست، بررسی این است که Policyهای تعریف‌شده واقعاً Enforcement شده‌اند.

یک روش مفید ایجاد Accountهایی با Scope متفاوت است.

مثلاً:

User A
User B
Manager
Administrator

سپس Matrix Permission ساخته شود.

مثلاً:

سپس سیستم باید تمام حالت‌های منفی را نیز Test کند.

OWASP برای بررسی IDOR نیز پیشنهاد می‌کند چند User با Authorization Scope متفاوت ایجاد شوند و دسترسی به Objectهای متعلق به یکدیگر آزمایش شود.

Negative Test چیست؟

بسیاری از Developerها فقط Test می‌کنند:

Admin می‌تواند User را Delete کند؟

اما تست امنیتی مهم‌تر:

Customer نمی‌تواند User را Delete کند؟

است.

Authorization Testing باید Allow و Deny را هر دو پوشش دهد.

Unit Test برای Authorization

فرض کنید Policy می‌گوید:

Owner می‌تواند Document را Edit کند.

Testها باید شامل این موارد باشند:

Owner → Allow
Other User → Deny
Unauthenticated → Deny
Disabled User → Deny

اگر Tenant وجود دارد:

Same Tenant → بر اساس Policy
Other Tenant → Deny

OWASP استفاده از Unit و Integration Test برای Authorization Logic را توصیه می‌کند، هرچند تأکید دارد این تست‌ها جای Penetration Test تخصصی را نمی‌گیرند.

Authorization Regression Testing چیست؟

فرض کنیم Access Control امروز درست است.

سه ماه بعد Developer Feature جدید اضافه می‌کند.

ممکن است Endpoint جدید Authorization نداشته باشد.

بنابراین Access Control Test باید وارد CI/CD شود.

بعد از هر تغییر:

Authorization Tests

دوباره اجرا شوند.

هدف این است که Permissionهای قبلی ناخواسته شکسته نشوند.

Logging برای Access Control Failure

اگر User تلاش کرد Resource غیرمجاز را بخواند، این Event می‌تواند ارزش Logging داشته باشد.

مثلاً:

User ID
Resource Type
Action
Timestamp
Result
Source

اما اطلاعات حساس نباید بی‌دلیل در Log نوشته شوند.

OWASP توصیه می‌کند Access Control Failureها Log شوند و در صورت رفتار تکرارشونده Alert ایجاد شود.

همچنین OWASP هشدار می‌دهد هم Logging بیش از حد و هم Logging ناکافی می‌تواند مشکل امنیتی ایجاد کند.

چه رفتارهایی باید Alert ایجاد کنند؟

مثلاً:

• صدها Access Denied در چند دقیقه؛
• تلاش مکرر برای Resourceهای Userهای دیگر؛
• درخواست زیاد به Admin Endpoint؛
• Cross-Tenant Access Attempt؛
• Request Methodهای غیرعادی؛
• Permission Change مشکوک.

یک Denied Request الزاماً Attack نیست.

اما Pattern رفتار اهمیت دارد.

خطر Error Messageهای بیش از حد دقیق

فرض کنید کاربر Resource غیرمجاز را درخواست کند.

Response:

این Invoice وجود دارد ولی متعلق به User دیگری است.

این Message اطلاعات اضافه‌ای درباره Resource افشا می‌کند.

گاهی Response عمومی‌تر مناسب‌تر است.

مثلاً:

Resource unavailable

یا Status Code متناسب با Architecture.

هدف این است که Error Handling هم امن باشد.

تفاوت 401 و 403

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

401 Unauthorized

معمولاً زمانی استفاده می‌شود که Authentication لازم است یا Credential معتبر وجود ندارد.

403 Forbidden

User شناخته شده، اما Permission لازم را ندارد.

البته معماری Application ممکن است برای کاهش Information Disclosure در برخی Resourceها Response دیگری انتخاب کند.

مهم‌تر از Code، Enforcement واقعی Authorization است.

Caching و Access Control

Caching نیز می‌تواند مسئله ایجاد کند.

فرض کنید Response خصوصی User A Cache شود و Cache Key User Identity را لحاظ نکند.

ممکن است User B همان Response را دریافت کند.

بنابراین برای Data خصوصی باید:

• Cache Policy
• Cache Key
• Authorization Context

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

در سیستم‌های CDN و Reverse Proxy این موضوع اهمیت زیادی دارد.

GraphQL و Access Control

GraphQL هم از قوانین Authorization مستثنا نیست.

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

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

• Resolver
• Service Layer
• Policy Engine

اعمال شود.

Object-Level و Field-Level Permission در GraphQLهای پیچیده اهمیت زیادی دارد.

Microserviceها و Authorization

در معماری Microservices تصمیم Access پیچیده‌تر می‌شود.

مثلاً:

API Gateway
↓
Order Service
↓
Payment Service

نباید فرض کرد چون Request از Gateway عبور کرده، هر Service می‌تواند Blindly Trust کند.

هر Service باید Context هویتی معتبر دریافت کند و Access Policy لازم را اجرا کند.

OWASP نیز برای REST Architecture تأکید می‌کند Access Control باید در Endpointهای غیرعمومی اجرا شود و Identity می‌تواند مرکزی باشد، اما Decision باید متناسب با Service Architecture انجام شود.

سرویس داخلی الزاماً Trusted نیست

یکی از اشتباهات رایج:

این Endpoint داخلی است، پس Authorization لازم ندارد.

اما اگر مهاجم به Internal Network یا Service دیگری دسترسی پیدا کند، همان Endpoint به هدف تبدیل می‌شود.

Zero Trust Architecture بر این اصل تأکید دارد که Location شبکه به‌تنهایی Trust ایجاد نمی‌کند.

Authentication و Authorization سرویس‌ها نیز باید طراحی شود.

اشتباهات رایج در پیاده‌سازی Broken Access Control

۱. بررسی فقط Login

Logged In بودن به معنی Permission داشتن نیست.

۲. مخفی کردن Button به‌جای Server Check

Frontend یک Security Boundary نیست.

۳. اعتماد به Object ID

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

۴. استفاده از UUID به‌عنوان تنها دفاع

UUID Guessing را سخت می‌کند ولی Authorization نیست.

۵. کنترل Role بدون Ownership

ممکن است دو User Role یکسان داشته باشند اما Resourceهای متفاوتی داشته باشند.

۶. استفاده بیش از حد از Admin Role

دادن Admin برای حل Permission Error اصل Least Privilege را نقض می‌کند.

۷. بررسی Authorization فقط روی GET

PUT، POST، PATCH، DELETE و Export نیز باید بررسی شوند.

۸. فراموش کردن Static File

Private PDF با URL غیرقابل حدس هنوز Access Control ندارد.

۹. CORS بیش از حد باز

Origin باید فقط براساس نیاز واقعی Allow شود.

۱۰. اعتماد به JWT بدون Validation

Token باید Signature و Claimهای لازم را Validate کند.

۱۱. Permission Check پراکنده

Authorization Logic بهتر است Centralized باشد.

۱۲. نبود Deny by Default

هر Access باید Explicitly Justified باشد.

۱۳. نبود Negative Test

فقط Scenario مجاز را Test نکنید.

۱۴. Roleهای قدیمی

Privilege Creep باید Periodically Review شود.

۱۵. نبود Logging

Repeated Access Failure باید قابل مشاهده باشد.

معماری پیشنهادی کنترل دسترسی امن

یک Request حساس می‌تواند از مسیر زیر عبور کند:

Request
↓
Authentication
↓
Session / Token Validation
↓
Identify User
↓
Identify Tenant
↓
Identify Resource
↓
Authorization Policy
↓
Ownership / Relationship Check
↓
Context / Business Rule Check
↓
Allow or Deny
↓
Audit Log

مهم است که ترتیب Policy به‌صورت معماری تعریف شود، نه اینکه Developer در هر Endpoint از ابتدا آن را اختراع کند.

چک‌لیست جلوگیری از Broken Access Control

Authentication

• User به‌درستی شناسایی می‌شود؟
• Session معتبر است؟
• Token معتبر است؟

Authorization

• هر Request Permission Check دارد؟
• Deny by Default اجرا شده؟
• Authorization در Server انجام می‌شود؟

Object Access

• Ownership بررسی می‌شود؟
• Tenant Scope بررسی می‌شود؟
• ID به‌تنهایی Trusted نیست؟

Role

• Least Privilege رعایت می‌شود؟
• Role اضافی وجود ندارد؟
• Privilege Creep بررسی می‌شود؟

API

• GET کنترل شده؟
• POST کنترل شده؟
• PUT/PATCH کنترل شده؟
• DELETE کنترل شده؟
• Export کنترل شده؟

Static Resource

• فایل خصوصی Authorization دارد؟
• Bucket عمومی ناخواسته نیست؟
• Backup در Web Root نیست؟

CORS

• Originها محدود هستند؟
• Credentialed Requestها دقیق تنظیم شده‌اند؟
• Origin ورودی کورکورانه Reflect نمی‌شود؟

Token

• JWT Signature بررسی می‌شود؟
• iss و aud بررسی می‌شوند؟
• Expiration مناسب است؟
• Revocation Strategy وجود دارد؟

Testing

• Userهای مختلف تست شده‌اند؟
• Negative Test وجود دارد؟
• Cross-Tenant Test وجود دارد؟
• Unit/Integration Test دارید؟

Monitoring

• Access Failure ثبت می‌شود؟
• رفتار تکراری Alert ایجاد می‌کند؟
• Log حاوی Sensitive Data اضافی نیست؟

آیا WAF جلوی Broken Access Control را می‌گیرد؟

نه به‌صورت کامل.

WAF ممکن است Requestهای مشکوک را شناسایی کند.

اما WAF معمولاً نمی‌داند:

User 125 مالک Invoice 892 است یا نه.

این Business Context داخل Application است.

بنابراین WAF یک Defense in Depth Layer است.

Access Control باید در Application Enforcement شود.

آیا 2FA Broken Access Control را حل می‌کند؟

خیر.

2FA Authentication را قوی می‌کند.

اگر یک User Legitimate با 2FA وارد شود ولی Application اجازه دسترسی به اطلاعات User دیگری را بدهد، مشکل Authorization همچنان وجود دارد.

پس:

2FA → Identity Protection
Authorization → Permission Protection

هردو لازم‌اند.

آیا HTTPS این آسیب‌پذیری را برطرف می‌کند؟

خیر.

HTTPS ارتباط را Encrypt می‌کند.

اما اگر Server خودش به User اشتباه Resource بدهد، TLS آن Response اشتباه را فقط به‌شکل امن منتقل می‌کند.

HTTPS ضروری است ولی Broken Access Control را حل نمی‌کند.

آیا امنیت URL کافی است؟

خیر.

URLهای:

• طولانی
• Hash شده
• UUID
• غیرقابل حدس

می‌توانند Discoverability را کاهش دهند.

اما Authorization باید همچنان Server-Side باشد.

Security by Obscurity نباید کنترل اصلی باشد.

آیا حذف لینک Admin از سایت کافی است؟

خیر.

Route باید Permission Check داشته باشد.

UI فقط Presentation است.

این اصل در:

• Website
• Mobile App
• SPA
• Desktop Client

یکسان است.

چه تیم‌هایی مسئول Access Control هستند؟

Broken Access Control فقط مشکل Developer نیست.

Product Team

باید Business Rule را تعریف کند.

Developer

باید Enforcement را صحیح پیاده‌سازی کند.

Security Team

Threat Model و Testing را انجام دهد.

QA

Permission Matrix را Test کند.

DevOps

Static Resources، Storage و Gateway را امن کند.

Management

Role و Access Review سازمانی را مدیریت کند.

Authorization یک Cross-Functional Requirement است.

سؤالات متداول درباره Broken Access Control

Broken Access Control چیست؟

Broken Access Control آسیب‌پذیری‌ای است که در آن Application به User اجازه مشاهده اطلاعات یا اجرای عملیاتی فراتر از Permission واقعی او می‌دهد.

چرا Broken Access Control خطرناک است؟

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

Broken Access Control چه رتبه‌ای در OWASP دارد؟

در OWASP Top 10:2025، Broken Access Control همچنان A01 و رتبه اول است.

تفاوت Authentication و Authorization چیست؟

Authentication هویت User را بررسی می‌کند. Authorization مشخص می‌کند همان User اجازه انجام چه Actionهایی را دارد.

IDOR چیست؟

IDOR زمانی رخ می‌دهد که Application Object Reference دریافت می‌کند اما Permission User برای همان Object را بررسی نمی‌کند.

آیا IDOR همان Broken Access Control است؟

IDOR یکی از زیرمجموعه‌های رایج Broken Access Control است.

Horizontal Privilege Escalation چیست؟

زمانی است که User به Resource متعلق به User دیگری با سطح Permission مشابه دسترسی پیدا می‌کند.

Vertical Privilege Escalation چیست؟

زمانی است که User به Function یا Permission سطح بالاتر مانند Administrator دست پیدا می‌کند.

آیا تغییر User ID در URL مشکل امنیتی است؟

وجود ID در URL به‌خودی‌خود Vulnerability نیست. مشکل زمانی است که Server Authorization همان Resource را بررسی نکند.

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

UUID Guessing را سخت‌تر می‌کند، اما OWASP تأکید می‌کند Access Control Check همچنان ضروری است.

Deny by Default چیست؟

یعنی اگر Permission به‌صراحت تأیید نشد، Access باید Deny شود.

Least Privilege چیست؟

User فقط حداقل Permissionهای موردنیاز برای انجام وظایف خود را دریافت می‌کند.

RBAC چیست؟

Role-Based Access Control اجازه‌ها را براساس Roleهایی مانند Customer، Editor و Administrator تعیین می‌کند.

ABAC چیست؟

Attribute-Based Access Control علاوه بر Role می‌تواند Attributeهایی مانند Resource، User، Device، Tenant یا Environment را برای تصمیم Authorization استفاده کند.

ReBAC چیست؟

Relationship-Based Access Control Permission را براساس Relation میان User و Resource تعیین می‌کند؛ مثلاً Owner بودن Document.

آیا Authorization باید روی تمام APIها باشد؟

بله. OWASP توصیه می‌کند REST Serviceهای غیرعمومی روی هر Endpoint Access Control داشته باشند.

آیا CORS بخشی از Access Control است؟

CORS مشخص می‌کند چه Originهایی می‌توانند Responseهای Cross-Origin را در Browser بخوانند. Misconfiguration آن می‌تواند Risk امنیتی ایجاد کند، اما CORS جایگزین Authorization خود API نیست.

آیا WAF Broken Access Control را متوقف می‌کند؟

نه همیشه، زیرا WAF معمولاً Business Relationship میان User و Resource را نمی‌داند.

آیا WordPress در برابر Broken Access Control مصون است؟

خیر. Plugin یا Code سفارشی می‌تواند Capability، Ownership یا Authorization را اشتباه پیاده‌سازی کند.

آیا WordPress Nonce همان Access Control است؟

خیر. Nonce عمدتاً برای جلوگیری از Requestهای ناخواسته کاربرد دارد و Permission User باید جداگانه بررسی شود.

چگونه Broken Access Control را تست کنیم؟

با Permission Matrix، چند Account دارای Scope متفاوت، Negative Testing، Object-Level Testing، Unit Test، Integration Test و Security Test مجاز.

آیا Penetration Test برای Access Control مفید است؟

بله. Automated Testها بسیار مفیدند اما OWASP نیز تأکید می‌کند Unit و Integration Test جای تست امنیتی تخصصی را به‌طور کامل نمی‌گیرند.

جمع‌بندی؛ چگونه از Broken Access Control جلوگیری کنیم؟

Broken Access Control یکی از بنیادی‌ترین مشکلات امنیت Web Application است و در OWASP Top 10:2025 همچنان در جایگاه A01 قرار دارد. این دسته زمانی ایجاد می‌شود که Application نتواند مرز بین «هویت User» و «Permission User» را به‌درستی اعمال کند.

Login موفق فقط ثابت می‌کند User چه کسی است.

پس از آن Application باید در هر درخواست بررسی کند:

• User چه Role و Attributeهایی دارد؟
• Resource متعلق به چه کسی است؟
• User با Resource چه Relationshipی دارد؟
• Tenant چیست؟
• Action چیست؟
• Business State اجازه Operation را می‌دهد یا خیر؟

یکی از مهم‌ترین اصول جلوگیری از Broken Access Control، استفاده از Deny by Default است. اگر Permission به‌صورت صریح تأیید نشده است، درخواست باید رد شود. OWASP همچنین توصیه می‌کند Permission روی هر Request بررسی شود و Security Decision در سمت Server یا زیرساخت Trusted اجرا شود.

اصل دوم، Least Privilege است. User، Service و Application Component نباید دسترسی بیش از نیاز داشته باشند.

در Object-Level Access نیز صرفاً داشتن ID یا UUID کافی نیست. Application باید Ownership و Scope Resource را بررسی کند. استفاده از UUID می‌تواند حدس زدن Object را سخت‌تر کند، اما جای Authorization را نمی‌گیرد.

APIها نیز باید در تمام Methodها کنترل شوند. GET، POST، PUT، PATCH، DELETE و Export هرکدام ممکن است Permission متفاوتی نیاز داشته باشند.

Static Fileها، Object Storage، PDFهای خصوصی و Backupها نیز نباید از Access Control خارج باشند. Resource خصوصی باید از طریق Mechanism کنترل‌شده در اختیار User قرار گیرد.

در Applicationهای ساده، RBAC می‌تواند کافی باشد؛ اما سیستم‌های پیچیده‌تر ممکن است از ABAC یا ReBAC برای تصمیم‌های Fine-Grained و Object-Level استفاده کنند.

Authorization Logic بهتر است Centralized و Reusable باشد و با Middleware، Policy یا Authorization Service یکپارچه اجرا شود. پراکنده کردن ده‌ها Permission Check دستی در Controllerها احتمال فراموش شدن یک Endpoint را افزایش می‌دهد.

در نهایت Access Control باید به‌طور مداوم Test شود.

Permission Matrix، Negative Testing، Cross-Tenant Testing، Unit Test، Integration Test و Penetration Test همگی در جلوگیری از Regression نقش دارند. OWASP نیز Automated Testing را برای Authorization Logic توصیه می‌کند، هرچند آن را جایگزین بررسی امنیتی حرفه‌ای نمی‌داند.

یک معماری امن کنترل دسترسی در ساده‌ترین حالت باید این زنجیره را حفظ کند:

Authentication
↓
Authorization
↓
Resource Ownership
↓
Tenant / Relationship
↓
Business Rules
↓
Deny or Allow
↓
Logging & Monitoring

اگر این تصمیم برای تمام Resourceها و تمام Requestهای حساس به‌صورت Server-Side و بر اساس اصل Least Privilege اجرا شود، بخش بزرگی از ریسک Broken Access Control قابل کنترل خواهد بود.