امنیت API چیست؟

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

یک استراتژی مؤثر امنیت API نه‌تنها از endpointهایی که کاربران مستقیماً با آن‌ها تعامل دارند محافظت می‌کند، بلکه سرویس‌های بک‌اند، محیط‌ها و مخازن داده‌ای را که این APIها با آن‌ها در ارتباط هستند نیز پوشش می‌دهد. به همین دلیل است که سازمان‌های آینده‌نگر به‌سمت رویکرد «شیفت به چپ» در امنیت حرکت کرده‌اند و امنیت را در تمام مراحل چرخه عمر API نهادینه می‌کنند.

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

رویکرد «شیفت به چپ» در امنیت API چگونه از مدل توسعه API-first پشتیبانی می‌کند؟

سازمان‌های مدرن APIها را در ابتدای مسیر توسعه می‌سازند تا به سرعت بیشتر در توسعه محصول، رشد اکوسیستم و تکرار سریع‌تر دست یابند. گزارش State of the API از Postman نشان می‌دهد که تعداد فزاینده‌ای از سازمان‌ها خود را API-first معرفی می‌کنند. با این حال، بدون ابزارهای مناسب برای مدیریت حتی تغییرات پایه‌ای API، تیم‌ها در معرض ریسک‌های امنیتی بالقوه قرار می‌گیرند.

در توسعه API-first، APIها پیش از برنامه‌هایی که به آن‌ها وابسته هستند ساخته می‌شوند. این موضوع به این معناست که امنیت باید رویکردی پیش‌دستانه داشته باشد، نه واکنشی. مدل امنیتی شیفت به چپ به تیم‌ها امکان می‌دهد:

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

رایج‌ترین تهدیدها و آسیب‌پذیری‌های امنیت API کدام‌اند؟

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

این دو فهرست طیف گسترده‌ای از آسیب‌پذیری‌ها را پوشش می‌دهند که می‌توان آن‌ها را در دسته‌های زیر طبقه‌بندی کرد:

بهداشت ضعیف امنیتی

این دسته ابتدایی‌ترین نوع آسیب‌پذیری‌های امنیتی است، اما در عین حال یکی از مهم‌ترین آن‌ها نیز محسوب می‌شود. رعایت نکردن اصول اولیه امنیت می‌تواند به رخنه‌های بزرگی منجر شود که به‌سادگی قابل پیشگیری بودند. برای مثال، تیم‌ها باید اطمینان حاصل کنند که توکن‌ها و کلیدهای API به‌صورت hard-code شده در کد منبع، تاریخچه Git یا مستندات قرار نگرفته‌اند.

همچنین استفاده از TLS برای رمزنگاری تمام ارتباطات API ضروری است، چه API به‌صورت REST مبتنی بر HTTP ارائه شود و چه به‌صورت gRPC مبتنی بر Protobuf.

آسیب‌پذیری‌های احراز هویت و مجوزدهی

APIها معمولاً بر اساس نقش کاربران، سطح دسترسی متفاوتی ارائه می‌دهند. بنابراین، مشکلات مربوط به احراز هویت و مجوزدهی تهدیدهای امنیتی جدی ایجاد می‌کنند، زیرا به کاربران اجازه می‌دهند اقداماتی انجام دهند یا به داده‌هایی دسترسی پیدا کنند که باید محدود شده باشند.

این مشکلات می‌توانند از مسیرهای مختلفی وارد API شوند. برای مثال، ممکن است سازمان‌ها بررسی مجوز در سطح متد را انجام ندهند تا تأیید شود شیء خوانده‌شده یا نوشته‌شده در محدوده مجاز کاربر قرار دارد. علاوه بر این، اگر مجوزدهی فقط در سطح endpoint انجام شود اما اشیای منفرد مجوزهای ریزتری داشته باشند، بررسی نادرست می‌تواند به نقض دسترسی منجر شود.
همچنین استفاده نکردن از روش‌های رمزنگاری مانند رمزنگاری کلید عمومی در فرآیندهای احراز هویت، ریسک جعل هویت (spoofing) را افزایش می‌دهد.

نبود دقت در مجوزهای خواندن و نوشتن

اشیای داده‌ای دارای ویژگی‌های متعددی هستند که برخی حساس و برخی غیرحساس‌اند. برای مثال، یک شیء User ممکن است شامل نام کاربری (غیرحساس) و رمز عبور (حساس) باشد. در برخی موارد، توسعه‌دهندگان به‌جای محافظت سمت سرور، فیلترکردن داده‌های حساس را به کلاینت واگذار می‌کنند. این کار باعث می‌شود داده‌های حساس برای بازیگران مخرب قابل دسترسی باشند؛ آسیبی که با نام «افشای بیش‌ازحد داده» شناخته می‌شود.

به همین شکل، کاربران نباید بتوانند ویژگی‌های داخلی مانند user.id یا ویژگی‌های مرتبط با مجوز مانند user.is_admin را تغییر دهند. با این حال، گاهی آسیب‌پذیری «mass assignment» ایجاد می‌شود؛ یعنی API تمام داده‌های دریافتی از کلاینت را بدون بررسی هم‌زمان تخصیص می‌دهد. راهکار صحیح، بررسی تک‌به‌تک ویژگی‌ها و اجازه تغییر فقط به موارد مجاز است.

عدم پیاده‌سازی سهمیه و محدودسازی

سهمیه‌بندی و throttling برای محدودکردن تعداد درخواست‌ها به یک سرویس طراحی شده‌اند تا منابع محاسباتی حفظ شوند و دسترس‌پذیری بالا باقی بماند. APIهایی که این مکانیزم‌ها را پیاده‌سازی نمی‌کنند در معرض حملات brute force قرار می‌گیرند که در آن مهاجم به‌صورت سیستماتیک رمز عبور را حدس می‌زند، و همچنین حملات منع سرویس (DoS) که با ارسال حجم بالای ترافیک، منابع سرویس را از کار می‌اندازد.

هدرهای HTTP نادرست یا ناقص

زمانی که یک کلاینت وب درخواست اولیه‌ای به API ارسال می‌کند، پاسخ باید شامل هدرهای HTTP مناسب، به‌ویژه هدرهای امنیتی، باشد. هدرهای امنیتی به مرورگر دستور می‌دهند چگونه به‌صورت امن با API تعامل کند. برای مثال، هدر HSTS می‌تواند ارتباط امن TLS و اعتبار گواهی‌ها را الزام‌آور کند و هدرهای Access-Control و CORP از سوءاستفاده کلاینت‌های معتبر جلوگیری می‌کنند.

علاوه بر این، تنظیم نادرست هدرهایی مانند Cache-Control و Vary می‌تواند در صورت استفاده از پراکسی یا load balancer باعث نشت داده‌های خصوصی به سایر کلاینت‌ها شود.

عدم اعتبارسنجی، پاک‌سازی و رمزگذاری ورودی‌ها در سطح متد

تزریق API زمانی رخ می‌دهد که مهاجم کد مخرب را از طریق پارامترها یا بدنه درخواست به API ارسال می‌کند. این کد ممکن است در سمت سرور اجرا شود، برای مثال در کوئری SQL یا هنگام غیر متمرکز کردن داده‌ها، یا در سمت کلاینت اجرا شود اگر در محتوای HTML قرار گیرد و به‌درستی خارج نشده باشد.

این کد مخرب می‌تواند مجوزها یا رکوردهای پایگاه داده را تغییر دهد یا حتی به اجرای کد از راه دور منجر شود. به همین دلیل استفاده از WAF و انجام اعتبارسنجی، پاک‌سازی و encoding ورودی‌ها در سطح متد حیاتی است. کتابخانه‌هایی مانند OWASP ESAPI می‌توانند به کاهش این آسیب‌پذیری کمک کنند.

فهرست‌برداری و مستندسازی نادرست

تیم‌ها معمولاً مسئول مدیریت تعداد زیادی از مصنوعات API مانند endpointها، نسخه‌ها و سرویس‌های شخص ثالث هستند. با افزایش این مصنوعات، مستندسازی و مدیریت امن آن‌ها دشوارتر می‌شود. برای مثال، اگر یک نسخه قدیمی API بازنشسته نشود، مهاجمان می‌توانند از آسیب‌پذیری‌ای سوءاستفاده کنند که بعداً اصلاح شده است. این مشکل که «مدیریت نادرست دارایی‌ها» نام دارد، زمانی تشدید می‌شود که مستندات به‌روز و کامل وجود نداشته باشد.

لاگ‌گیری و پایش ناکافی

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

برخی بهترین شیوه‌های امنیت API کدام‌اند؟

هر API نیازهای امنیتی خاص خود را دارد، اما اصول زیر به‌طور کلی توصیه می‌شوند:

• استفاده از HTTPS برای رمزنگاری داده‌ها
• پیاده‌سازی rate limiting و throttling
• اعتبارسنجی و پاک‌سازی تمام ورودی‌ها
• پایش مداوم فعالیت‌های مشکوک
• پیاده‌سازی کنترل دسترسی مبتنی بر نقش (RBAC)

برخی نمونه‌های رایج از رخنه‌های امنیت API

رخنه‌های امنیتی API معمولاً از الگوهای حمله مشابهی پیروی می‌کنند و می‌توانند پیامدهای شدیدی برای کسب‌وکار داشته باشند، از جمله:

• حملات brute force برای حدس زدن رمزها و کلیدها
• حملات DoS برای از کار انداختن سرویس
• حملات تزریقی برای تغییر داده‌ها یا سرقت توکن‌ها
• حملات مرد میانی برای دستکاری داده‌های در حال انتقال