نشت داده‌ها از طریق BOLA و تزریق پرامپت؛ حفره‌های امنیتی در استک API

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

در سال ۲۰۲۶، مجوزدهی سطح شیء شکست‌خورده (BOLA) — شبیه به داشتن کلید ورودی که اجازه می‌دهد هر دری در ساختمان باز شود — همچنان رایج‌ترین علت نشت داده‌ها در دنیای واقعی است. این مشکل به این دلیل تداوم می‌یابد که در حالی که تیم‌ها اغلب هویت یک کاربر را تایید می‌کنند، اما مکرراً فراموش می‌کنند بررسی کنند که آیا آن کاربر واقعاً مالک داده‌ای است که درخواست کرده یا خیر.

این آسیب‌پذیری یک توکن جلسه (Session Token) معتبر را به یک کلید جامع برای دسترسی غیرمجاز به داده‌ها تبدیل می‌کند. از آنجایی که شرکت‌ها اکنون APIها را پیش از رابط‌های کاربری (UI) عرضه می‌کنند، این نقاط اتصال به جذاب‌ترین هدف در پشته نرم‌افزاری مدرن تبدیل شده‌اند. طبق اعلام ورایزون در گزارش بررسی‌های نقض داده‌های ۲۰۲۵، حملات به اپلیکیشن‌های وب و APIها اکنون در صدر مسیرهای تاییدشده برای دسترسی غیرقانونی قرار دارند.

تیم‌های امنیتی مدرن با شکافی رو به گسترش مواجه هستند زیرا ترافیک در حال تغییر از نشست‌های مرورگر (Browser Sessions) به سمت فراخوانی‌های ماشین-به-ماشین است. این فراخوانی‌ها به‌طور تاریخی کمتر از ورودهای کاربر نظارت می‌شوند و همین امر یک نقطه کور برای مهاجمان ایجاد می‌کند تا از آن بهره‌برداری کنند.

شکاف مجوزدهی

سازمان OWASP در لیست ۱۰ مورد برتر امنیت API سال ۲۰۲۳، مورد BOLA را در رتبه اول (API1) قرار داد و خاطرنشان کرد که این نقص با وجود اینکه به‌خوبی شناخته شده است، همچنان پابرجاست. این خطا معمولاً در سطح نقطه اتصال (Endpoint) رخ می‌دهد؛ برای مثال، درخواستی به /api/orders/12345 ممکن است هویت فراخواننده را تایید کند اما در تایید مالکیت سفارش ۱۲۳۴۵ شکست بخورد. مهاجم با تغییر ساده این شناسه (ID)، می‌تواند داده‌های دیگران را بخواند یا آن‌ها را تغییر دهد.

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

علاوه بر این، تیم‌ها باید تست‌های خودکار fuzzer مجوزدهی را روی مجموعه‌ی APIهای خود اجرا کنند و با آن همان سخت‌گیری‌ای را داشته باشند که در مورد تست‌های عملکردی دارند. گزارش وضعیت API شرکت پست‌من (Postman) تایید می‌کند که تست مجوزدهی برای چندین سال متوالی، یکی از رایج‌ترین مراحلی بوده است که در جریان‌های کاری توسعه نادیده گرفته شده است. به همین دلیل است که BOLA همچنان در گزارش‌های شکار باگ (Bug Bounty) حکمرانی می‌کند؛ زیرا تیم‌ها هنوز به اشتباه احراز هویت (Authentication) و مجوزدهی (Authorization) را به عنوان یک مشکل واحد می‌بینند.

ریسک‌های API مخصوص مدل‌های زبانی

APIهایی که به‌عنوان رابط مدل‌های زبانی عمل می‌کنند، کلاسی از تهدیدات جدید را معرفی می‌کنند که REST APIهای استاندارد با آن‌ها روبرو نیستند. OWASP در لیست ۱۰ مورد برتر برای اپلیکیشن‌های LLM، به‌طور خاص مواردی چون تزریق پرامپت (Prompt Injection)، عاملیت بیش از حد (Excessive Agency) و مدیریت ناامن خروجی‌ها را به عنوان ریسک‌های پیشرو شناسایی کرده است. این آسیب‌پذیری‌ها مستقیماً از طریق لایه API ظاهر می‌شوند و تنها محدود به ویجت‌های چت نیستند.

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

برای APIهایی که از فراخوانی تابع (Function Calling) یا استفاده از ابزارها بهره می‌برند، ریسک‌ها افزایش می‌یابد. شما باید هر ابزار را به‌صورت محدود تعریف کرده و از لیست‌های مجاز (Allowlists) صریح استفاده کنید. اعطای دسترسی گسترده به مدل به نقاط اتصال داخلی، در صورت دستکاری مدل از طریق تزریق پرامپت، یک حفره امنیتی عظیم ایجاد می‌کند.

همچنین محدودیت نرخ (Rate Limiting) باید تکامل یابد. به جای شمارش ساده درخواست‌ها، محدودیت‌ها باید بر اساس هزینه توکنی (Token Cost) و هزینه عملیات پایین‌دستی که یک فراخوانی می‌تواند تحریک کند، اعمال شود؛ چرا که یک پرامپت می‌تواند به ده‌ها فراخوانی داخلی تبدیل شود. هنگامی که عامل‌های هوشمند (AI Agents) به‌طور خودکار APIها را فراخوانی می‌کنند، باید برای هر عامل یک اعتبارنامه کوتاه‌مدت و با محدوده دسترسی کم صادر شود. استفاده از یک حساب سرویس مشترک خطرناک است، زیرا یک عامل لو رفته، دسترسی کامل به تمام عامل‌های دیگر را فراهم می‌کند.

اعتماد صفر و اجرای درگاه

امنیت مبتنی بر محیط (Perimeter) برای خدماتی که در چندین ابر پخش شده‌اند، با ادغام‌های شخص ثالث در ارتباط هستند یا توسط عامل‌های هوش مصنوعی با زمان‌بندهایی که شما کنترل نمی‌کنید فراخوانی می‌شوند، منسوخ شده است. گارتنر پیش‌بینی می‌کند که با حرکت سازمان‌ها به سمت معماری اعتماد صفر (Zero Trust)، هزینه کرد برای درگاه‌های API (API Gateways) افزایش یابد، زیرا تشخیص داده‌اند که ترافیک API در اکثر سازمان‌ها اکنون از ترافیک وب سنتی پیشی گرفته است.

استراتژی‌های کلیدی اجرا در سطح درگاه عبارتند از:

• استفاده از TLS متقابل (mTLS) بین سرویس‌ها تا هر دو طرف اتصال را احراز هویت کنند.
• تغییر از کلیدهای API طولانی‌مدت به توکن‌های کوتاه‌مدت OAuth 2.0.
• تعریف محدوده‌های (Scopes) دقیق (مانند orders:read یا orders:write) برای کاهش اثر تخریبی یک توکن لو رفته.
• اعمال محدودیت نرخ و سیاست‌های سهمیه بر اساس هویت کلاینت و نه آدرس IP؛ زیرا محدودیت‌های مبتنی بر IP در برابر ترافیک توزیع‌شده یا کلاینت‌های چندمستأجره که زیرساخت مشترک دارند، شکست می‌خورند.

بحران مدیریت اسرار

قرار دادن اعتبارنامه‌های سخت‌افزاری (Hardcoded) در مخازن کد، همچنان یکی از علل اصلی نشت‌های قابل‌پیشگیری است. برنامه اسکن اسرار گیت‌هاب (GitHub) میلیون‌ها اعتبارنامه لو رفته را در مخازن عمومی شناسایی کرده است که بسیاری از آن‌ها کلیدهای API محیط تولید (Production) بودند که توسط توسعه‌دهندگانی ارسال شده بودند که قصد داشتند آن‌ها را پیش از Push حذف کنند.

تیم‌های مهندسی باید اسرار را در خزانه‌های تخصصی مانند HashiCorp Vault، AWS Secrets Manager یا معادل‌های ارائه‌دهندگان ابری ذخیره کنند. دریافت اعتبارنامه‌ها در زمان اجرا (Runtime) به جای جاسازی آن‌ها در فایل‌های پیکربندی یا متغیرهای محیطی که در کنترل نسخه (Version Control) ثبت می‌شوند، ریسک افشا را به‌شدت کاهش می‌دهد.

برای حفظ بهداشت امنیتی، سازمان‌ها باید:

• کلیدهای API و اسرار امضا را طبق یک برنامه زمانی ثابت بچرخاند (Rotate).
• در صورت خروج عضو تیم یا وقوع حادثه‌ای که نشان‌دهنده افشای رمز باشد، بلافاصله چرخش را اجرا کنند.
• توکن‌های امضاشده کوتاه‌مدت را به کلیدهای استاتیک ترجیح دهند، زیرا توکنی که در عرض چند دقیقه منقضی می‌شود، آسیب بسیار کمتری نسبت به یک کلید نامحدود می‌زند.
• اسکن خودکار اسرار را به خط لوله CI اضافه کنند تا هر اعتبارنامه ارسال شده، فرآیند ادغام (Merge) را متوقف کند.

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

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

گام بعدی شما

• تمام نقاط اتصال API خود را برای بررسی مالکیت شیء (Object Ownership) بازبینی کنید.
• لایه‌های اعتبارسنجی سخت‌گیرانه را بین خروجی مدل‌های زبانی و عملیات حساس پایگاه‌داده قرار دهید.
• اسکنرهای خودکار اسرار را در گیت‌هاب یا GitLab برای تمام مخازن فعال کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.