API Testing — تست امنیت ای‌پی‌آی

تست نفوذ API چیست و چرا با تست وب کلاسیک فرق دارد؟

در یک برنامه‌ی وب کلاسیک، رابط کاربری هم نقشه‌ی راه است و هم محدودکننده. در API چنین نقشه‌ای وجود ندارد: سطح حمله مجموعه‌ای از اندپوینت است که فقط از سه راه کشف می‌شود — مستندسازی رسمی (OpenAPI، WSDL، مجموعه‌ی Postman)، ترافیک واقعی کلاینت، و شناسایی روی جاوااسکریپت باندل‌شده و نسخه‌های قدیمی مسیرها.

سه تفاوت ساختاری که روش کار را عوض می‌کنند:

• هر اندپوینت یک تصمیم مجوزدهی مستقل است. در UI پنهان کردن یک دکمه ظاهراً مسئله را حل می‌کند؛ در API چیزی برای پنهان کردن نیست.
• احراز هویت معمولاً توکن‌محور است — JWT، توکن Bearer یا کلید API — با همه‌ی مسائل اعتبارسنجی امضا، انقضا و دامنه‌ی اعتبار.

مرجع درست کدام است؟ WSTG تنها یک آزمون API دارد

این را باید صریح گفت: بخش تست API در راهنمای آزمون OWASP، یعنی WSTG-APIT، در نسخه‌ی پایدار v4.2 تنها یک آزمون دارد و آن هم GraphQL است. WSTG v4.2 متدولوژی جامعی برای REST نیست؛ ادعای «تست کامل API بر اساس WSTG» یا به بخش‌های عمومی راهنما اشاره دارد یا دقیق نیست.

مرجع درست، OWASP API Security Top 10 نسخه‌ی ۲۰۲۳ است:

ترکیب عملی در متدولوژی تست نفوذ: پوشش آزمون از WSTG برای لایه‌های عمومی، و دسته‌بندی ریسک از API Security Top 10.

غالب‌ترین دسته: مجوزدهی در سطح شیء، ویژگی و عملیات

سه رتبه از پنج رتبه‌ی نخست فهرست ۲۰۲۳ درباره‌ی مجوزدهی است: تزریق را می‌توان ساختاری حل کرد، اما مجوزدهی نیاز به تصمیم دارد و تصمیم فراموش می‌شود.

• BOLA همان چیزی است که در وب IDOR می‌نامیم: کاربر شناسه‌ی شیء را عوض می‌کند و برنامه مالکیت را بررسی نمی‌کند.
• BFLA یعنی دسترسی به یک عملیات غیرمجاز — اجرای DELETE روی منبعی که فقط GET آن مجاز بود، یا رسیدن مستقیم به مسیرهای مدیریتی.
• BOPLA در نسخه‌ی ۲۰۲۳ دو دسته‌ی جداگانه‌ی نسخه‌ی قبل را ادغام کرده است: افشای بیش‌ازحد داده (پاسخ فیلدهایی را برمی‌گرداند که UI صرفاً نمایششان نمی‌دهد) و تخصیص انبوه یا Mass Assignment (کلاینت فیلدهایی می‌فرستد که نباید قابل نوشتن باشند).

PATCH /api/v1/users/me HTTP/1.1
Content-Type: application/json

{"displayName":"ali","role":"admin"}

HTTP/1.1 200 OK
{"id":42,"displayName":"ali","role":"admin"}

روش کشف، روش دو حسابی است: دو حساب هم‌سطح بسازید، جریان‌های کاری را با هر دو اجرا کنید، سپس شناسه‌ها و بدنه‌های حساب دوم را در نشست حساب اول بازپخش کنید. هیچ اسکنری این را قابل اتکا پیدا نمی‌کند، چون نمی‌داند کاربر A باید به رکورد B دسترسی داشته باشد یا نه.

مصرف منابع، محدودسازی نرخ و جریان‌های حساس

API4:2023 درباره‌ی نبودِ سقف است، نه فقط «تعداد درخواست در دقیقه»:

• پارامترهای صفحه‌بندی بدون سقف — ?limit=1000000 که پایگاه‌داده و حافظه را می‌بلعد.
• هزینه‌ی مالی مستقیم: ارسال پیامک، ایمیل و فراخوانی سرویس ثالث پولی — جایی که نبود سقف به هزینه‌ی واقعی تبدیل می‌شود.
• محدودسازی نرخ تک‌بُعدی: سقف مبتنی بر IP که با X-Forwarded-For دور می‌خورد، یا سقف مبتنی بر حساب که با ساخت حساب جدید بی‌اثر می‌شود.

لایه‌ی بعدی API6:2023 است: جریان‌هایی که هر درخواستشان مشروع است اما خودکارسازی‌شان کسب‌وکار را می‌شکند — مثل شرایط رقابتی، با اسکنر پیدا نمی‌شود.

GraphQL و gRPC

GraphQL تنها آزمون بخش WSTG-APIT است و مسائل خاص خودش را دارد:

• Introspection: اگر فعال باشد، کل شِما با یک کوئری در دسترس است. در محیط عملیاتی باید خاموش باشد، اما خاموش کردنش «کاهش سطح افشا» است، نه کنترل دسترسی.
• Batching: ارسال چند عملیات در یک درخواست، سقف‌های مبتنی بر شمارش درخواست را دور می‌زند و آزمون‌های حدس رمز یا کد یک‌بارمصرف را ارزان می‌کند.
• تودرتویی عمیق: روابط دوطرفه اجازه می‌دهند کوئری‌ای ساخته شود که به‌صورت نمایی رشد کند؛ بدون سقف عمق و سقف پیچیدگی، این یک مسیر ساده‌ی اختلال سرویس است.
• مجوزدهی در سطح فیلد: رایج‌ترین اشتباه، بررسی مجوز فقط روی گره‌ی ریشه است؛ فیلد تودرتویی مثل user { email } از کنار آن رد می‌شود.

POST /graphql HTTP/1.1
Content-Type: application/json

{"query":"{ __schema { types { name } } }"}

gRPC جنس دیگری دارد: پیام‌های Protocol Buffers روی HTTP/2. محتوا باینری است، پس پروکسی رهگیر بدون فایل‌های .proto یا فعال بودن Server Reflection فقط بایت می‌بیند. روال عملی: ابتدا تعریف سرویس را به‌دست آورید، پیام‌ها را بازسازی کنید، بعد همان پرسش‌های مجوزدهی را بپرسید. برای اشکال‌زدایی فریم HTTP/2، Wireshark واقعاً به کار می‌آید.

ابزارها و روش عملی اجرا

سه ابزار نقش روشنی دارند:

• Burp Suite: اسکنر آن تعریف API را مستقیماً می‌پذیرد — OpenAPI (JSON یا YAML)، WSDL برای SOAP، مجموعه‌ی Postman با قالب صادراتی v2.1.0، و GraphQL از راه introspection. محدودیت‌های مستندشده: ارجاع بیرونی در OpenAPI/WSDL پشتیبانی نمی‌شود، آدرس سرور باید مطلق باشد، محیط‌ها و اسکریپت‌های Postman پشتیبانی نمی‌شوند، و بدنه‌های file، formdata و graphql خارج از پوشش‌اند (جزئیات).
• Postman: ابزار توسعه و QA است، نه ابزار امنیتی، و تشخیص آسیب‌پذیری ندارد؛ نقشش تولید ترافیک قابل رهگیری و ساختن همان مجموعه‌ای است که به اسکنر می‌دهید.
• mitmproxy: رهگیری اسکریپت‌پذیر و بدون رابط گرافیکی، با افزونه‌های پایتون برای بازنویسی خودکار درخواست/پاسخ و کار روی ترافیک اپلیکیشن موبایل. اسکنر و معادل Repeater ندارد؛ مکمل پروکسی اصلی است، نه جایگزین.

اشتباهات رایج و نگاشت به استانداردها

باور غلط دوم: «اسکنر خودکار API را پوشش می‌دهد.» اسکنر برای تزریق، هدرها و CVEهای شناخته‌شده مفید است، اما BOLA و BFLA و منطق کسب‌وکار خارج از توان ساختاری اوست — همان نکته‌ای که در امنیت برنامه‌ی وب تکرار می‌شود: ابزار پوشش می‌دهد، انسان تصمیم را می‌سنجد.

نگاشت: در OWASP Top 10:2025 بیشتر یافته‌های API زیر A01 کنترل دسترسی شکسته و A02 پیکربندی نادرست می‌نشینند. شناسه‌های CWE پرکاربرد: CWE-639 (دور زدن مجوزدهی با کلید تحت کنترل کاربر)، CWE-862 (نبود مجوزدهی)، CWE-915 (تغییر کنترل‌نشده‌ی ویژگی‌های شیء — پایه‌ی تخصیص انبوه) و CWE-770 (تخصیص منابع بدون سقف).

پرسش‌های متداول