ریسک‌های بالقوه استفاده از APIهای شخص ثالث (Potential Risks of Using Third-Party APIs)
تصور کنید در یک مسیر طولانی رانندگی می‌کنید و به تونلی می‌رسید که می‌تواند زمان سفر شما را چند ساعت کاهش دهد. شما جلوی مانع توقف می‌کنید و می‌گویید: «می‌توانم از اینجا عبور کنم؟»
مأمور پاسخ می‌دهد: «البته! ماشینت را روی کامیون می‌گذاریم، من آن را از تونل عبور می‌دهم و در طرف دیگر منتظر تو هستم.»
آیا کلید ماشین خود را بدون بررسی مجوز مأمور، وضعیت کامیون یا بیمهٔ آن‌ها تحویل می‌دهید؟
این استعاره ظریف نیست، اما دقیقاً همان کاری است که بسیاری از توسعه‌دهندگان هنگام ثبت‌نام و شروع استفاده از APIهای شخص ثالث بدون بررسی قبلی انجام می‌دهند.
طبق نظرسنجی Gartner 2024 API Strategy Survey، ۸۲٪ از پاسخ‌دهندگان از APIها در سازمان خود استفاده می‌کنند و ۷۱٪ از آن‌ها از APIهای ارائه شده توسط شخص ثالث (فروشندگان SaaS) استفاده می‌کنند. بدون اتخاذ تدابیر مناسب برای اطمینان از پیاده‌سازی امن، این موضوع می‌تواند مشکل‌ساز شود.
در ادامه، به عواملی که رشد APIهای شخص ثالث را تحریک می‌کنند، مشکلات ناشی از استفاده بی‌احتیاط از آن‌ها و روش‌هایی برای کاهش این ریسک‌ها می‌پردازیم.
۱. اعتماد کورکورانه به داده‌های سرویس‌ها
حدود سه چهارم سازمان‌ها به نوعی به APIهای شخص ثالث متکی هستند. با افزایش ادغام هوش مصنوعی مولد در محصولات، که توسط APIهایی مانند OpenAI تسهیل می‌شود، انتظار می‌رود درصد ۷۱٪ ذکر شده حتی بالاتر برود.
مشکل این است که با تبدیل شدن برخی APIها به استاندارد رایج، ممکن است بدون سؤال و بررسی به داده‌های بازگردانده شده اعتماد کنیم. این مسئله فقط به APIهای مرتبط با GenAI محدود نمی‌شود، بلکه شامل APIهایی است که پیش‌تر به عنوان «استاندارد طلایی» شناخته می‌شدند.
به‌عنوان مثال، شکایات اخیر درباره افت کیفیت Google Maps را در نظر بگیرید. این API توسط Domino’s، Uber و میلیون‌ها سازمان دیگر استفاده شده است. حتی با وجود نگرانی‌ها درباره مسیرها و به‌روزرسانی داده‌ها، شرکت‌ها همچنان به استفاده از آن ادامه می‌دهند. هیچ API، حتی با ارائه‌دهندهٔ معروف، مصون از خطا نیست.
۲. توهمات و ریسک‌های LLM (برای APIهای GenAI شخص ثالث)
در پستی درباره ارتقای ویژگی‌های محصولات با هوش مصنوعی مولد، ذکر شد که Air Canada مجبور شد تخفیفی را که یک چت‌بات وعده داده بود جبران کند. دادگاه‌های کانادا تعیین کردند که چت‌بات نمی‌تواند به‌عنوان یک نهاد حقوقی مستقل مسئول باشد، موضوعی که برای محصولات GenAI با APIهای شخص ثالث اهمیت دارد.
OWASP در Top 10 For LLM Applications به خطرات وابستگی بیش از حد به LLM اشاره کرده است:
«سیستم‌ها یا افراد بیش از حد به LLMها متکی باشند بدون نظارت، ممکن است با اطلاعات نادرست، سوءتفاهم، مسائل قانونی و آسیب‌پذیری‌های امنیتی مواجه شوند.»
این بدان معنا نیست که ارزش APIهای GenAI نادیده گرفته شود، اما باید در طول فرآیند پیاده‌سازی و ارزیابی مورد توجه قرار گیرد.
۳. اعتبارسنجی نامناسب ورودی داده‌ها
OWASP اشاره می‌کند که برخی توسعه‌دهندگان ممکن است بیش از حد به داده‌های دریافتی از APIهای شخص ثالث اعتماد کنند. به‌ویژه در مورد APIهای قدیمی و معتبر، ممکن است استانداردهای امنیتی ضعیف‌تری اتخاذ شود.
اعتبارسنجی نحوی و معنایی ورودی‌ها می‌تواند تأثیر SQL Injection و دیگر حملات را کاهش دهد. این شامل بررسی صحت نحو فیلدهای ساختاریافته یا تطابق مقادیر با متن زمینه‌ای است. اعتبارسنجی ورودی باید همواره در تعامل با داده‌های دریافتی از APIهای شخص ثالث در نظر گرفته شود.
۴. قطع سرویس و حملات DoS
بسیاری از ارائه‌دهندگان API صفحات وضعیت (Status Pages) دارند که شامل زمان آپتایم، رخدادهای گذشته و دیگر اطلاعات مرتبط است. به‌عنوان مثال، API OpenAI در زمان نگارش این متن، آپتایمی برابر با ۹۹٫۸۶٪ دارد. بررسی زمان پاسخ‌دهی به مشکلات و آپتایم کلی سرویس به شما دیدی از واکنش سریع ارائه‌دهندگان نسبت به قطعی‌ها می‌دهد.
حملات DDoS تهدیدی جدی برای APIهای شخص ثالث هستند و محدودسازی نرخ (Rate Limiting) روش مؤثری برای کاهش تأثیر آن‌هاست. ارائه‌دهنده‌ای که قصد استفاده از آن را دارید، آیا این تدابیر را دارد؟
۵. نسخه‌بندی یا تغییرات ناسازگار سمت مشتری
ارائه نسخه‌های جدید API معمولاً خوب است، زیرا شامل رفع مشکلات یا افزودن پارامترها و endpoints جدید می‌شود. اما نسخه‌بندی مکرر ممکن است منجر به تغییرات ناسازگار شود که مصرف‌کننده API را دچار مشکل کند تا زمانی که مستندات به‌روز شوند.
گاهی توسعه‌دهندگان مستندات مربوط به نسخه‌های منسوخ API را نگه می‌دارند، همراه با توضیحات تغییرات اصلی. بررسی این اطلاعات به شما کمک می‌کند فراوانی تغییرات و مشکلات گذشته را بهتر تحلیل کنید.
۶. مدیریت نادرست موجودی و Shadow APIs
طبق OWASP API Security Top 10، مدیریت نامناسب موجودی API ریسک بزرگی ایجاد می‌کند؛ مثلاً نسخه‌های قدیمی API یا endpoints متروکه (Zombie) که بدون patch یا با استانداردهای امنیتی ضعیف باقی می‌مانند.
در مورد Shadow APIها، ممکن است سازمان اصلاً API خود را مدیریت یا ایمن نکند. شناسایی نقاط کور مستندسازی و جریان داده‌ها قبل از استفاده از API همواره اقدامی هوشمندانه است. OWASP پیشنهاد می‌کند به موارد زیر توجه کنید:
-
شفافیت هدف میزبان API و دسترسی شبکه‌ای کاربران
-
نسخه فعال API و برنامه‌های بازنشستگی آن
-
میزان و نحوهٔ اشتراک داده‌های حساس
-
به‌روز بودن و شفاف بودن مستندات، و تطابق با استانداردهایی مانند OpenAPI Specification
نتیجه‌گیری
ساخت محصول روی زیرساخت دیگران همیشه همراه با ریسک است. استفاده از APIهای شخص ثالثی که به‌درستی ایمن نشده‌اند یا قابل اعتماد نیستند، می‌تواند به مشکلات جدی یا حداقل ناراحتی‌های خفیف منجر شود.
با گسترش طراحی API-first و فشار برای ادغام قابلیت‌های GenAI، انتظار داریم مصرف APIها در سال‌های آینده افزایش یابد. بررسی عملکرد، نسخه‌بندی و امنیت APIهای شخص ثالث قبل از استفاده ضروری است. حتی اگر قبلاً به‌طور کامل بررسی نکرده‌اید، هنوز زمان خوبی برای ممیزی و ارزیابی آن‌هاست.
به‌عنوان یک توسعه‌دهنده API، شما می‌دانید نشانه‌های کیفیت API چیست. اگر API شخص ثالث دارای نقص‌هایی است که در API خود آن‌ها را نمی‌پذیرفتید، بهتر است از آن اجتناب کنید. یا به استعاره پیشین برگردیم: به دنبال تونل دیگری باشید…
