امنیت Api| اگر با دنیای API و داده‌های وب‌سایت‌ها آشنا باشید، می‌دانید که API در هر ثانیه در معرض خطر است. از پرداخت‌های مالی که ممکن است دور زده شوند (در بهترین حالت!) گرفته تا استخراج غیرقانونی داده‌ها (Data Scraping) و دسترسی‌های ناخواسته به اطلاعات کاربران.

طبق گزارش OWASP API Security Top 10، بیش از ۸۰٪ از حملات مربوط به API به دلیل خطاهای رایجی مثل احراز هویت ضعیف (Broken Authentication)، کنترل دسترسی ناقص (Broken Authorization) یا نشت داده (Data Exposure) رخ می‌دهند.

در سال‌های اخیر، سرویس‌های بزرگ مثل Facebook، Twitterو حتی T-Mobile دچار رخنه‌های امنیتی از طریق API شده‌اند. یعنی حملات فقط برای تازه‌کارها نیست؛ بلکه حتی شرکت‌هایی با تیم‌های امنیتی حرفه‌ای هم گاهی از جزیی‌ترین خطاها ضربه خورده‌اند — مثل نداشتن محدودیت در تعداد درخواست‌ها (Rate Limiting)، یا بی‌توجهی به اعتبارسنجی توکن‌ها.

نکته جالب اینجاست که اکثر این رخنه‌ها به خاطر ضعف در منطق پایه‌ی امنیت (Security Logic) هستند، نه پیچیدگی فنی. مثلاً وقتی یک API بدون احراز هویت درست (Authentication) یا بدون محدودیت سطح دسترسی (Authorization) منتشر می‌شود، در واقع خودش دعوت‌نامه‌ای برای هکرها می‌فرستد.

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

برای آشنایی بیشتر با مفاهیم پایه‌ی API و انواع آن، می‌توانید مقاله‌ی “API چیست؟ ” و “انواع API از نظر سبک طراحی” را مطالعه کنید.

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

تقریباً هر API، حتی اگر کوچک و ساده باشد، می‌تواند دروازه‌ای برای ورود مهاجمان (Attackers) باشد. تفاوت فقط در میزان خسارتی است که ممکن است وارد شود. تهدیدهای امنیتی (Security Threats) در APIها از چند مسیر اصلی وارد می‌شوند :

 ۱. احراز هویت ضعیف (Weak Authentication)

وقتی سیستم شما به هر کسی اجازه می‌دهد توکن (Token) بسازد، بدون بررسی درست هویت او، یعنی توکن شما کارت دعوت هکر ها است. مثلاً اگر API کلید ثابت (Static API Key) دارد که بین چند کاربر به اشتراک گذاشته می‌شود، کافی است یک نفر آن را در مرورگر ببیند تا تمام دسترسی‌ها لو برود.

بخواهم یه نمونه ساده بگویم، فرض کنید توکن بدون تاریخ انقضا روی مخزن گیت هاب خود تعریف کرده باشید، اگر این توکن دزدیده شود باید با مخزن خود خداحافظی کنید. البته این شاید سطحی ترین اتفاقی بود که برای توکن بدون تاریخ انقضا رخ می دهد.

در REST و RPC که معمولاً Stateless هستند، این اشتباه زیاد دیده می‌شود چون توسعه‌دهنده فکر می‌کند «کلید دسترسی» خودش امنیت کافی دارد. اما بهترین روش استفاده از JWT (JSON Web Token) یا OAuth 2.0 است که توکن‌ها را به هویت کاربر و زمان محدود متصل می‌کند.

۲. کنترل دسترسی ناکامل (BOLA (Broken Object Level Authorization))

حتی اگر کاربر احراز هویت شده باشد، هنوز باید بررسی شود که آیا حق انجام آن عملیات را دارد یا نه.

در بسیاری از APIها (مخصوصاً SOAP و REST)، توسعه‌دهندگان فقط بررسی می‌کنند که توکن معتبر است، اما فراموش می‌کنند نقش کاربر (Role) یا سطح دسترسی (Permission Level) را چک کنند.

مثلاً فرض کنید کاربری با نقش عادی بتواند درخواست حذف کاربر دیگر را بفرستد چون endpoint مربوطه هیچ بررسی اضافه‌ای ندارد. به این نوع خطا Insecure Direct Object Reference (IDOR) هم گفته می‌شود (از رایج‌ترین روش‌های نفوذ در API)

۳. نشت داده‌ها (Data Exposure)

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

در SOAP یا RPC که ساختار پاسخ‌ها سنگین‌تر است، این اتفاق خیلی راحت می‌افتد چون توسعه‌دهنده برای راحتی کار، کل شیء (Object) را برمی‌گرداند.

راه‌حل؟ همیشه از Response Filtering یا Data Sanitizationاستفاده کنید تا فقط داده‌ی ضروری بازگردانده شود.

۴. تزریق‌ها (Injection Attacks)

حمله‌های تزریق (Injection) از قدیمی‌ترین و در عین حال خطرناک‌ترین‌ها هستند. در APIها، این حملات معمولاً از ورودی‌های کاربر (User Inputs) وارد می‌شوند — مثل پارامترهای Query، بدنه درخواست (Request Body)، یا Headerها.

این خطا زمانی رخ می‌دهد که توسعه‌دهنده، ورودی کاربر (مثلاً نام کاربری یا یک فیلد جستجو) را به صورت خام در یک کوئری پایگاه داده (SQL) قرار می‌دهد، بدون اینکه مطمئن شود شامل کدهای مخرب نیست. در نتیجه، ورودی کاربر تبدیل به دستور اجرایی در سرور می‌شود🙄

مشهورترین نوع آن SQL Injectionاست، و Command Injection ،LDAP Injectionو NoSQL Injection هم از انواع دیگر آنها است.

در WebSocketها که داده به‌صورت زنده تبادل می‌شود، اعتبارسنجی ورودی‌ها (Input Validation) حیاتی‌تر هم می‌شود.

نوع دیگر Mass Assignment است، این خطا ناشی از یک تکنیک برنامه‌نویسی راحت اما ناامن است.(قابل توجه برنامه نویسان تازه کار) توسعه‌دهنده به جای تعریف تک‌تک فیلدهایی که باید به‌روزرسانی شوند، به سیستم می‌گوید که “تمام فیلدهایی که در JSON ورودی آمده را به شیء پایگاه داده اعمال کن.”اگر مهاجم فیلدی مانند is_admin: true را به ورودی اضافه کند، به طور ناخواسته نقش مدیریتی به او داده می‌شود.

۵. محدود نکردن نرخ درخواست‌ها (Lack of Rate Limiting)

یکی از ساده‌ترین اما مؤثرترین حملات، Brute Force یا «حدس مکرر» است. در این روش، مهاجم با ارسال هزاران درخواست در چند ثانیه، سعی می‌کند رمز یا توکن درست را پیدا کند.

اگر API شما محدودیتی برای تعداد درخواست‌ها نداشته باشد، به‌راحتی قربانی می‌شود.

در REST و WebSocket به‌ویژه، این مشکل زیاد دیده می‌شود چون توسعه‌دهنده‌ها گاهی تصور می‌کنند کاربران همیشه خوش‌نیت‌اند!

البته دیدگاهی که رنج کشیده (بخوانید هک شده‌گان) دارند :

راه‌حل این است که با ابزارهایی مثل  express-rate-limit در Node.js یا API Gatewayپدر سطح زیرساخت، نرخ درخواست را کنترل کنید.

۶. نبود رمزنگاری (Lack of Encryption)

ارسال داده‌ها روی کانال‌های ناامن (مثل HTTP به‌جای HTTPS) باعث می‌شود مهاجم بتواند ترافیک را شنود کند (Sniffing) و اطلاعات را بدزدد.

در WebSocketها، همیشه از نسخه‌ی امن آن یعنیWSS (WebSocket Secure) استفاده کنید.

همچنین مطمئن شوید که داده‌های حساس در سمت سرور هم در حالت سکون (At Rest) رمزگذاری شده باشند.

۷. پیکربندی نادرست (Security Misconfiguration)

گاهی مشکل از کد نیست، از تنظیمات است. APIهایی که روی سرورهای عمومی با پورت‌های باز، هدرهای پیش‌فرض (Default Headers) یا نسخه‌های قدیمی نرم‌افزار اجرا می‌شوند، مثل درهای نیمه‌باز برای نفوذگرها هستند.

در SOAP مخصوصاً، تنظیمات XML Parser و Schema Validation اهمیت بالایی دارد چون آسیب‌پذیری‌هایی مثل XXE (XML External Entity) از همین مسیر وارد می‌شوند.

این تهدیدات، هفت دشمن اصلی هر API هستند.

خوب است اینهارا هم بدانید :

10 آسیب بحرانی امنیت در API  از منظر OWASP.

خبر خوب اینکه بیشتر این آسیب ها با رعایت چند اصل ساده قابل پیشگیری‌اند.

این راهکار ها را در مقاله “راهکار های افزایش امنیت در سبک‌های مختلف API “برسی خواهیم کرد.