arrow_backبازگشت به یادداشت‌های میدانی
WEB SECURITY منتشر شده 7 Jul 2026

بررسی عمیق: مبانی امنیت API

شکستی عملی از امنیت API: ریسک‌های کلیدی، OWASP API Top 10، و دفاعیاتی که هر توسعه‌دهنده باید بشناسد.

API‌ها بافت اتصال‌دهنده نرم‌افزار مدرن هستند و برنامه‌های موبایل، میکروسرویس‌ها و یکپارچگی‌های طرف ثالث را تقویت می‌کنند. از آنجایی که آن‌ها منطق برنامه و داده‌ها را مستقیماً در معرض قرار می‌دهند، API‌ها هدف مورد علاقه مهاجمان شده‌اند. امنیت API رشته‌ای از طراحی، تست و دفاع این رابط‌ها در برابر سوء‌استفاده است.

چه چیزی API‌ها را متفاوت می‌سازد

بر خلاف صفحات وب سنتی، API‌ها از طریق قالب‌های داده‌ای ساختار‌یافته مانند JSON یا XML ارتباط برقرار می‌کنند، اغلب با نظارت انسانی کمینه. این بدان معناست:

  • سطح حملات بالاتر در هر endpoint — هر مسیر API اساساً برنامه‌ای کوچک است با احراز هویت، اعتبارسنجی و منطق کسب‌وکاری خود.
  • اعتماد ماشین به ماشین — سرویس‌ها اغلب فرض می‌کنند که اگر درخواست دارای توکن معتبری باشد، قانونی است، چیزی که مهاجمان از طریق سرقت توکن یا تکرار بهره می‌برند.
  • تغییر سریع — API‌ها سریع تکامل می‌یابند و endpoint‌های "سایه" بدون اسناد یا منسوخ شده اغلب از بررسی‌های امنیتی فرار می‌کنند.

کلاس‌های آسیب‌پذیری مشترک

OWASP API Security Top 10 مشکلات رایج‌تری را که در سیستم‌های تولیدی دیده می‌شوند به تصویر می‌کشد:

  • Broken Object Level Authorization (BOLA) — کاربر می‌تواند داده‌های کاربر دیگری را با تغییر ساده ID در درخواست دسترسی داشته باشد، زیرا سرور مالکیت را تایید نمی‌کند.
  • Broken Authentication — مدیریت توکن ضعیف، شناسه‌های جلسه قابل پیش‌بینی یا نرخ محدود‌کردن گمشده روی endpoint‌های ورود.
  • Excessive Data Exposure — API‌ها اشیاء کامل پایگاه داده بازمی‌گردانند و به کلاینت تکیه می‌کنند تا فیلدهای حساس را فیلتر کند.
  • Lack of Resources & Rate Limiting — بدون تنظیم دوره، مهاجمان می‌توانند اعتبارات را بروت‌فورس کنند یا منابع backend را تخلیه کنند.
  • Broken Function Level Authorization — کاربران عادی به endpoint‌های فقط مدیر می‌رسند زیرا بررسی‌های نقش گمشده یا ناسازگار هستند.
  • Mass Assignment — پذیرش فیلدهای کاربر (مانند isAdmin) مستقیماً در مدل‌های پایگاه داده بدون فیلتر.
  • Security Misconfiguration — پیام‌های خطا تفصیلی، endpoint‌های debug در معرض، یا سرآیندهای امنیتی گمشده.
  • Injection — ورودی بدون تمیز به SQL، NoSQL یا ترجمه‌کننده‌های دستوری از طریق پارامترهای API.

اصول احراز هویت و اعتبارسنجی

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

  • از پروتکل‌های استاندارد صنعتی مانند OAuth 2.0 یا OpenID Connect استفاده کنید به جای طرح‌های توکن سفارشی.
  • JWT‌ها را به درستی تایید کنید — امضا، انقضا، صادرکننده و ادعاهای مخاطب را بررسی کنید؛ هرگز به توکن بدون امضا یا alg: none اعتماد نکنید.
  • بررسی‌های سطح object را server-side اعمال کنید: هر درخواستی که به شناسه منبع اشاره کند باید تایید کند که فراخوانی‌کننده واقعاً مالک است یا حقوق آن منبع را دارد.
  • اصل کمترین امتیاز را به API key‌ها و حساب‌های سرویس اعمال کنید، آن‌ها را باریک محدود کنید تا از دسترسی گسترده جلوگیری شود.

اعتبارسنجی ورودی و کنترل خروجی

هر پارامتر API — شامل سرآیندها، رشته‌های query و فیلدهای nested JSON — را به عنوان ورودی ناموثوق در نظر بگیرید:

  • انواع داده، طول و قالب‌ها را با استفاده از اعتبارسنجی schema (مثلاً JSON Schema یا اعتبارسنج‌های مبتنی بر OpenAPI) تایید کنید.
  • از allowlist برای فیلدهای مورد انتظار در هنگام deserialization استفاده کنید تا از حملات mass assignment جلوگیری کنید.
  • فقط فیلدهایی را بازگردانید که کلاینت واقعاً نیاز دارد؛ از dump کردن اشیاء داخلی کامل در پاسخ‌ها اجتناب کنید.
  • پاسخ‌های خطا را استاندارد کنید تا stack trace، مسیرهای داخلی یا جزئیات پایگاه داده را نشت ندهند.

Rate Limiting، Monitoring و Logging

حتی API‌های خوب‌احراز‌هویت نیاز به حفاظت در برابر الگوهای سوء‌استفاده دارند:

  • rate limiting برای هر کاربر و برای هر IP اعمال کنید تا تلاش‌های brute-force و scraping را کند کنید.
  • رویدادهای احراز هویت، عدم موفقیت‌های اعتبارسنجی و الگوهای دسترسی غیر معمول را برای تجزیه‌وتحلیل بعدی log کنید.
  • برای ناهنجاری‌هایی مانند افزایش ناگهانی درخواست‌ها به endpoint‌های حساس یا دسترسی از جغرافیاهای غیرمنتظره monitor کنید.
  • فهرست دقیقی از API را تحت نگهداری کنید — شما نمی‌توانید آنچه را ایمن کنید که وجود آن را نمی‌دانید، بنابراین endpoint‌های منسوخ یا سایه را ردیابی و بازنشستهٔ کنید.

رویکردهای تست عملی

امن کردن API فرآیند مستمر است، نه تک‌بار audit:

  • ابزارهای خاص API (مانند مجموعه‌های Postman همراه با اسکنرهای امنیتی) را در pipeline‌های CI/CD گنجانید.
  • برای نقص‌های اعتبارسنجی تست دستی انجام دهید، زیرا اسکنرهای خودکار اغلب BOLA و مسائل منطق تجاری را miss می‌کنند.
  • مستندات API (OpenAPI/Swagger specs) را با پیاده‌سازی واقعی همگام نگه دارید تا blind spot‌ها در هنگام تست جلوگیری شود.
  • یکپارچگی‌های API طرف ثالث را با همان دقتی که کد خود را می‌کنید بررسی کنید، زیرا یک API طرف ثالث مصالح‌آمیز می‌تواند بردار حمله شود.

نظرات پایانی

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

برای ساخت درک عمیق‌تر و عملی از این مفاهیم، بخش‌های مرتبط Korra Studio را در مورد امنیت برنامه کاربردی وب و طراحی احراز هویت کاوش کنید.

با کمک هوش مصنوعی نوشته‌شده، بازبینی و منتشر‌شده توسط Michal Pilch (CISSP)، Korra Studio.

آماده برای پیش‌رفت بیشتر؟

این یکی از یادداشت‌های پایگاه دانش Korra Studio است — پلتفرم هر موضوع را با مربی یک‌به‌یک جفت می‌کند.

شروع رایگانarrow_forward