APIها امروز بخش مهمی از معماری نرم‌افزارهای سازمانی، اپلیکیشن‌های موبایل، سامانه‌های ابری و معماری Microservices را تشکیل می‌دهند. تقریباً هرجا دو سامانه نیاز به تبادل اطلاعات داشته باشند، احتمال استفاده از API وجود دارد. همین گستردگی باعث شده است APIها به یکی از نقاط مهم مورد توجه مهاجمان تبدیل شوند.
مشکل اصلی اینجاست که امنیت یک API فقط به استفاده از HTTPS یا قرار دادن Authentication در ابتدای درخواست محدود نمی‌شود. ممکن است کاربر به‌درستی احراز هویت شود، اما بتواند اطلاعات کاربر دیگری را مشاهده کند، عملیاتی خارج از سطح دسترسی خود انجام دهد یا با ارسال تعداد زیادی Request منابع یک سرویس را مصرف کند. به همین دلیل داشتن یک چک‌لیست امنیت API می‌تواند به تیم‌های امنیت، توسعه و DevSecOps کمک کند تا APIها را به‌صورت ساختاریافته ارزیابی کنند. یکی از معتبرترین منابع در این زمینه، پروژه OWASP API Security Top 10 است که مهم‌ترین ریسک‌های امنیتی مرتبط با APIها را معرفی می‌کند. نسخه 2023 این پروژه شامل ده گروه اصلی از ریسک‌های API است.
چرا به چک‌لیست امنیت API نیاز داریم؟
بررسی امنیت API بدون چارچوب مشخص معمولاً به چند تست محدود مانند بررسی Authentication، SQL Injection یا Rate Limiting ختم می‌شود. اما بسیاری از حملات مهم API به منطق دسترسی، سطح مجوز کاربران، ارتباط میان Objectها و Business Logic مربوط هستند. یک چک‌لیست امنیت API مناسب باید بتواند حداقل سه موضوع را پوشش دهد:
- آیا کاربر همان کسی است که ادعا می‌کند؟
- آیا کاربر فقط به داده‌ها و عملیات مجاز خود دسترسی دارد؟
آیا API در برابر سوءاستفاده از منابع و منطق کسب‌وکار مقاوم است؟
OWASP API Security Top 10 می‌تواند پایه مناسبی برای طراحی چنین چک‌لیستی باشد.
بررسی Broken Object Level Authorization یا BOLA
اولین ریسک OWASP در نسخه 2023، Broken Object Level Authorization است. این آسیب‌پذیری زمانی ایجاد می‌شود که API شناسه یک Object را از کاربر دریافت کند، اما بررسی نکند که آیا همان کاربر واقعاً مجاز به مشاهده یا تغییر آن Object است یا خیر. OWASP این موضوع را یکی از ریسک‌های مهم و رایج APIها معرفی می‌کند. برای مثال:
GET /api/users/125/orders
اگر کاربر بتواند عدد 125 را به 126 تغییر دهد و اطلاعات سفارش‌های کاربر دیگری را مشاهده کند،API دارای ضعف Authorization است.
بیشتر بخوانید: بررسی پورتال API برای VMware Tanzu: کشف، مدیریت و مستندسازی APIهای داخلی به‌صورت یکپارچه
در چک‌لیست امنیت API باید این موارد را بررسی کنید:
- آیا مجوز دسترسی برای هر Object در سمت سرور کنترل می‌شود؟
- آیا تغییر ID در URL یا Request Body باعث دسترسی به اطلاعات کاربر دیگری می‌شود؟
- آیا UUID یا شناسه‌های پیچیده به‌اشتباه جایگزین Authorization شده‌اند؟
- آیا عملیات Read،Update و Delete همگی جداگانه کنترل می‌شوند؟
بررسی Broken Authentication
Authentication مشخص می‌کند چه کسی درخواست را ارسال کرده است. اگر مکانیزم Authentication ضعیف باشد، مهاجم ممکن است Token ،Session یا Credential کاربران را به دست آورد. OWASP، پیاده‌سازی نادرست Authentication را دومین ریسک اصلی API Security در فهرست 2023 معرفی کرده است.
موارد مهم در چک‌لیست:
- آیا API از مکانیزم استاندارد Authentication استفاده می‌کند؟
- آیا Tokenها دارای Expiration مناسب هستند؟
- آیا Refresh Token به‌درستی محافظت می‌شود؟
- آیا پس از Logout ،Session یا Tokenمعتبر باقی می‌ماند؟
- آیا Login Endpoint دارای Rate Limiting است؟
- آیا برای حساب‌های حساس امکان استفاده از MFA وجود دارد؟
APIهایی که از JWT استفاده می‌کنند نیز باید Algorithm ،Signature ،Expiration و اعتبار Claims را به‌درستی بررسی کنند.
Broken Object Property Level Authorization
در این ضعف، ممکن است کاربر مجاز به دسترسی به یک Object باشد اما نباید تمام Propertyهای آن را مشاهده یا تغییر دهد. برای مثال یک API ممکن است اطلاعات پروفایل کاربر را برگرداند:
name
email
role
isAdmin
اگر API بدون کنترل Propertyها اجازه دهد کاربر مقدارisAdmin یاrole را تغییر دهد، یک مشکل جدی امنیتی ایجاد می‌شود. این دسته در نسخه 2023 OWASP بر ضعف‌های Authorization در سطح Property تمرکز دارد.
بیشتر بخوانید: بررسی تاثیر نقض امنیتی و اهمیت پالیسی در محافظت از API
بایستی این موارد را چک کنید:
- API دقیقاً چه فیلدهایی را در Response برمی‌گرداند؟
- آیا فیلدهای حساس بدون نیاز واقعی نمایش داده می‌شوند؟
- آیا Client می‌تواند Propertyهای مدیریتی را تغییر دهد؟
- آیا Allowlist برای فیلدهای قابل‌ویرایش تعریف شده است؟
Unrestricted Resource Consumption
APIها می‌توانند منابعی مانند CPU ،RAM ،Storage، پهنای باند و اتصال Database را مصرف کنند. اگر محدودیتی وجود نداشته باشد، مهاجم می‌تواند تعداد زیادی Request ارسال کرده و منابع سرویس را اشغال کند. بنابراین در چک‌لیست امنیت API باید موارد زیر بررسی شوند:
- Rate Limiting
- محدودیت تعداد Request
- محدودیت حجم Upload
- محدودیت تعداد Recordهای بازگردانده‌شده
- Pagination
- Timeout مناسب
- محدودیت مصرف منابع برای عملیات پرهزینه
این ریسک در OWASP 2023 با عنوان Unrestricted Resource Consumption معرفی شده است.
Broken Function Level Authorization
در این آسیب‌پذیری، کاربر معمولی ممکن است بتواند Endpointهایی را فراخوانی کند که فقط برای Administrator در نظر گرفته شده‌اند. برای مثال:
DELETE /api/admin/users/152
پنهان کردن این Endpoint در رابط کاربری کافی نیست. Authorization باید در سمت سرور اعمال شود. چک کنید:
- آیا Role کاربران برای عملیات حساس کنترل می‌شود؟
- آیا User معمولی می‌تواند Admin Endpointها را فراخوانی کند؟
- آیا HTTP Methodهای مختلف روی یک Endpoint دارای کنترل مجزا هستند؟
- آیا مجوزها به‌صورت Centralized مدیریت می‌شوند؟
Unrestricted Access to Sensitive Business Flows
گاهی مشکل امنیتی یک ضعف فنی کلاسیک نیست، بلکه مهاجم از منطق اصلی کسب‌وکار سوءاستفاده می‌کند. برای مثال API ممکن است برای خرید بلیت، ثبت سفارش، ارسال پیام، دریافت OTP یا رزرو یک محصول استفاده شود.
اگر مهاجم بتواند این عملیات را هزاران بار به‌صورت خودکار اجرا کند، حتی بدون دور زدن Authentication ممکن است خسارت ایجاد شود. OWASP در نسخه 2023 این موضوع را به‌طور مستقل در دسته Unrestricted Access to Sensitive Business Flows قرار داده است.
در ارزیابی بررسی کنید:
- کدام عملیات API ارزش مالی یا تجاری دارند؟
- آیا Bot می‌تواند این عملیات را خودکار کند؟
- آیا Rate Limit متناسب با منطق کسب‌وکار وجود دارد؟
- آیا رفتارهای غیرعادی شناسایی می‌شوند؟
نکته مهم این است که امنیت API تنها با بررسی چند تنظیم فنی یا اجرای یک اسکن آسیب‌پذیری تأمین نمی‌شود. بسیاری از ضعف‌های جدی API زمانی ایجاد می‌شوند که میان Authentication ،Authorization، منطق کسب‌وکار و نحوه دسترسی کاربران به داده‌ها هماهنگی کافی وجود نداشته باشد. به همین دلیل یک چک‌لیست امنیت API مؤثر باید علاوه بر آسیب‌پذیری‌های فنی، نحوه عملکرد واقعی API در سناریوهای مختلف را نیز بررسی کند؛ به‌خصوص زمانی که کاربران با سطح دسترسی متفاوت، سرویس‌های ثالث و چندین Application از یک API مشترک استفاده می‌کنند.
در بخش دوم این مقاله، بررسی چک‌لیست امنیت API بر اساس OWASP API Security Top 10 را ادامه می‌دهیم و به ریسک‌های مهم دیگری مانند سوءاستفاده از فرآیندهای حساس کسب‌وکار، SSRF، پیکربندی نادرست امنیتی، مدیریت نامناسب Inventory و خطرات استفاده از APIهای شخص ثالث می‌پردازیم. همچنین در پایان، یک چک‌لیست عملی برای ارزیابی Authentication ،Authorization ،Configuration ،Logging و Monitoring ارائه خواهیم کرد تا بتوان از این چارچوب به‌صورت عملی در فرآیند توسعه، DevSecOps و ارزیابی امنیت APIهای سازمانی استفاده کرد.
