امنیت API چیست؟ راهنمای کامل جلوگیری از هک API سایت

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

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

اهمیت موضوع زمانی بیشتر می‌شود که بدانیم APIها معمولاً به اطلاعات و منطق اصلی برنامه دسترسی دارند. اطلاعات کاربران، سفارش‌ها، تراکنش‌ها، پیام‌ها، فایل‌ها، تنظیمات و بسیاری از عملیات مهم کسب‌وکار ممکن است از طریق Endpointهای API قابل دسترسی باشند.

OWASP نیز APIها را بخش مهمی از معماری برنامه‌های موبایل، SaaS، وب و سامانه‌های مدرن می‌داند و تأکید می‌کند که APIها به دلیل در معرض قرار دادن منطق برنامه و داده‌های حساس، به یکی از اهداف مهم حملات تبدیل شده‌اند.

موضوع امنیت API تنها به «قرار دادن یک API Key» یا «استفاده از HTTPS» خلاصه نمی‌شود. احراز هویت، مجوزدهی، کنترل دسترسی به Objectها، مدیریت Token، Rate Limiting، محدودسازی مصرف منابع، اعتبارسنجی ورودی، مدیریت نسخه‌های قدیمی، ثبت رویدادهای امنیتی، CORS، ارتباط با سرویس‌های ثالث و حتی نحوه طراحی Business Flow همگی بخشی از امنیت API هستند.

در نسخه 2023 فهرست OWASP API Security Top 10 نیز Authorization همچنان یکی از مهم‌ترین چالش‌های امنیت API معرفی شده و چند مورد از ریسک‌های اصلی مستقیماً به کنترل دسترسی مربوط هستند.

در این مقاله از رخنه کاو بررسی می‌کنیم امنیت API چیست، چرا APIها هدف جذابی برای مهاجمان هستند، مهم‌ترین آسیب‌پذیری‌های API کدام‌اند، REST API و GraphQL چگونه باید ایمن شوند و چه اقداماتی می‌توان برای جلوگیری از هک API سایت انجام داد.

API چیست و چرا امنیت آن اهمیت دارد؟

API مخفف Application Programming Interface است و به زبان ساده، واسطه‌ای برای ارتباط دو بخش نرم‌افزاری با یکدیگر محسوب می‌شود.

فرض کنید کاربر اپلیکیشن فروشگاه را باز می‌کند و وارد صفحه سفارش‌های خود می‌شود. اپلیکیشن معمولاً تمام اطلاعات سفارش‌ها را داخل خود ذخیره نکرده است. در عوض یک Request به API سرور ارسال می‌کند و Backend پس از بررسی هویت و دسترسی کاربر، اطلاعات مناسب را برمی‌گرداند.

مسیر ساده می‌تواند به شکل زیر باشد:

کاربر → اپلیکیشن → API → Backend → Database

در بسیاری از برنامه‌های مدرن، رابط کاربری فقط لایه‌ای برای نمایش اطلاعاتی است که API مدیریت می‌کند.

Endpoint چیست؟

Endpoint آدرس مشخصی از API است که یک قابلیت یا Resource خاص را ارائه می‌دهد.

برای مثال ممکن است API مسیرهایی برای:

• دریافت پروفایل
• مشاهده سفارش‌ها
• ایجاد سفارش
• ویرایش اطلاعات
• آپلود فایل
• دریافت گزارش
• ورود کاربر

داشته باشد.

هر Endpoint باید مانند یک در ورودی مستقل به Backend در نظر گرفته شود.

اگر یک برنامه صدها Endpoint داشته باشد، هرکدام می‌توانند بخشی از Attack Surface سیستم باشند.

امنیت API چیست؟

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

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

این تعریف سه بخش مهم دارد:

کاربر باید درست شناسایی شود.

کاربر باید اجازه انجام عملیات موردنظر را داشته باشد.

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

مشکل زمانی ایجاد می‌شود که یکی از این مرزها به‌درستی پیاده‌سازی نشده باشد.

چرا APIها هدف جذابی برای مهاجمان هستند؟

API معمولاً رابط مستقیم‌تری نسبت به صفحات HTML در اختیار Client قرار می‌دهد.

در نتیجه مهاجم با بررسی Traffic برنامه ممکن است ساختار Requestها، شناسه Resourceها، فیلدهای ورودی و عملیات مختلف را مشاهده کند.

دسترسی مستقیم به داده‌ها

APIها معمولاً داده را به شکل ساختاریافته مانند JSON برمی‌گردانند.

اگر Authorization ضعیف باشد، ممکن است دسترسی غیرمجاز به اطلاعات بسیار ساده‌تر شود.

منطق کسب‌وکار

API فقط داده منتقل نمی‌کند.

گاهی عملیات‌هایی مانند:

• خرید
• انتقال
• ایجاد حساب
• دریافت تخفیف
• ارسال پیام
• ایجاد سفارش

را اجرا می‌کند.

سوءاستفاده از چنین قابلیت‌هایی می‌تواند حتی بدون وجود یک Bug کلاسیک، به کسب‌وکار آسیب بزند.

استفاده گسترده در موبایل

اپلیکیشن موبایل معمولاً API خود را در اختیار Client قرار می‌دهد.

نباید تصور کرد چون کد اپلیکیشن در Store منتشر شده، Endpointهای Backend مخفی باقی می‌مانند.

امنیت باید در سمت سرور اعمال شود.

تفاوت Authentication و Authorization در امنیت API

این دو مفهوم بسیار مهم هستند و نباید با یکدیگر اشتباه گرفته شوند.

Authentication چیست؟

Authentication یا احراز هویت پاسخ می‌دهد:

«این کاربر چه کسی است؟»

برای مثال کاربر از طریق:

• Username و Password
• Token
• OAuth
• Passkey
• Certificate

هویت خود را اثبات می‌کند.

Authorization چیست؟

Authorization پاسخ می‌دهد:

«این کاربر اجازه انجام چه کاری را دارد؟»

ممکن است API مطمئن باشد درخواست متعلق به کاربر آریا است، اما همچنان باید بررسی کند آیا آریا اجازه مشاهده فایل کاربر دیگری را دارد یا خیر.

به همین دلیل داشتن JWT معتبر به معنی مجاز بودن تمام درخواست‌ها نیست.

چرا Frontend نباید مسئول امنیت API باشد؟

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

برای مثال دکمه «حذف کاربر» برای User عادی نمایش داده نمی‌شود.

این طراحی از نظر رابط کاربری درست است، اما کنترل امنیتی محسوب نمی‌شود.

اگر Endpoint مربوط به حذف کاربر در Backend بررسی نکند که Request از مدیر سیستم آمده است، مهاجم ممکن است بدون نیاز به دکمه رابط کاربری مستقیماً Endpoint را فراخوانی کند.

قاعده مهم این است:

Frontend قابل اعتماد نیست و تمام کنترل‌های امنیتی مهم باید در Backend اجرا شوند.

OWASP API Security Top 10 چیست؟

OWASP پروژه‌ای اختصاصی برای امنیت API دارد که مهم‌ترین ریسک‌های متداول APIها را دسته‌بندی می‌کند. نسخه 2023 این پروژه دومین نسخه اصلی API Security Top 10 است.

ده ریسک اصلی نسخه 2023 عبارت‌اند از:

شناخت این موارد چارچوب بسیار مناسبی برای بررسی امنیت API ایجاد می‌کند.

Broken Object Level Authorization یا BOLA چیست؟

BOLA یکی از مهم‌ترین ضعف‌های امنیت API است.

فرض کنید کاربر از API برای دریافت یک سفارش استفاده می‌کند.

در Request شناسه سفارش ارسال می‌شود و سرور سفارش را از Database دریافت می‌کند.

مشکل زمانی ایجاد می‌شود که سرور فقط بررسی کند کاربر Login کرده است اما بررسی نکند سفارش موردنظر واقعاً متعلق به همان کاربر است.

OWASP تأکید می‌کند هر Endpoint که شناسه یک Object را از Client دریافت و روی آن عملیات انجام می‌دهد باید Authorization در سطح Object را بررسی کند.

چرا استفاده از ID تصادفی مشکل را به‌تنهایی حل نمی‌کند؟

گاهی تصور می‌شود اگر IDها از نوع UUID باشند، BOLA برطرف می‌شود.

UUID می‌تواند Guess کردن شناسه را سخت‌تر کند، اما Authorization نیست.

اگر کاربر به هر شکلی شناسه معتبر Resource دیگری را به دست آورد، Backend همچنان باید مالکیت یا Permission او را بررسی کند.

راهکار جلوگیری از BOLA

در هر عملیات باید مشخص شود:

کاربر چه کسی است؟

Resource موردنظر چیست؟

آیا این کاربر روی این Resource مشخص اجازه این عملیات را دارد؟

کنترل باید در Backend و برای تمام مسیرهای مرتبط اعمال شود.

Broken Authentication چیست؟

Authentication ضعیف می‌تواند مهاجم را قادر کند هویت یک User یا Service را تصاحب کند.

مشکلات رایج می‌توانند شامل موارد زیر باشند:

• رمزهای ضعیف
• Tokenهای قابل پیش‌بینی
• Sessionهای بدون انقضا
• Rate Limiting ناکافی
• Password Reset ناامن
• نگهداری نامناسب Token
• MFA ضعیف یا غیرفعال

چرا Authentication API اهمیت بیشتری دارد؟

در API، Requestها به‌صورت خودکار قابل ارسال هستند.

اگر Endpoint ورود محدودیت مناسبی نداشته باشد، حملات Brute Force یا Credential Stuffing می‌توانند با سرعت بالا اجرا شوند.

بنابراین Login API نیز باید Rate Limiting، Logging و کنترل‌های ضد اتوماسیون داشته باشد.

Broken Object Property Level Authorization چیست؟

گاهی کاربر اجازه دسترسی به یک Object را دارد، اما نباید تمام فیلدهای آن را ببیند یا تغییر دهد.

برای مثال یک API اطلاعات User را برمی‌گرداند.

ممکن است Response شامل:

نام

تصویر

ایمیل

Role داخلی

وضعیت حساب

شناسه‌های مدیریتی

باشد.

User عادی شاید فقط باید نام و تصویر را مشاهده کند.

اگر Backend تمام Object را بدون کنترل Propertyها Serialize کند، اطلاعات اضافه افشا می‌شوند.

Mass Assignment

مشکل مشابهی در Request نیز اتفاق می‌افتد.

فرض کنید API اطلاعات Profile را به‌روزرسانی می‌کند.

Client فقط باید بتواند name و avatar را تغییر دهد.

اما اگر Backend تمام فیلدهای JSON را مستقیماً به Model منتقل کند، ممکن است فیلدهای داخلی ناخواسته نیز تحت تأثیر قرار گیرند.

راهکار مناسب استفاده از Allowlist مشخص برای فیلدهای قابل خواندن و قابل تغییر است.

Unrestricted Resource Consumption چیست؟

هر Request API مقداری Resource مصرف می‌کند.

این Resource می‌تواند شامل:

• CPU
• RAM
• Database Connection
• Storage
• Bandwidth
• SMS
• Email
• سرویس خارجی

باشد.

اگر محدودیت مناسبی وجود نداشته باشد، مهاجم یا حتی یک Client معیوب می‌تواند منابع را بیش از حد مصرف کند.

OWASP این مسئله را در API4:2023 با عنوان Unrestricted Resource Consumption مطرح کرده است.

مثال‌های کاربردی

یک Endpoint تولید PDF ممکن است CPU زیادی مصرف کند.

یک Endpoint ارسال OTP می‌تواند هزینه پیامک ایجاد کند.

یک API جستجو می‌تواند Queryهای سنگین Database اجرا کند.

در نتیجه Rate Limit نباید برای همه Endpointها یکسان باشد.

Rate Limiting در امنیت API

Rate Limiting تعداد Requestهای مجاز را در بازه زمانی مشخص کنترل می‌کند.

محدودیت می‌تواند براساس:

• IP
• User ID
• API Key
• Session
• Device
• Endpoint

اعمال شود.

چرا Rate Limit باید Endpoint-Specific باشد؟

درخواست دریافت پروفایل ممکن است بسیار سبک باشد.

اما درخواست Export کامل اطلاعات می‌تواند منابع زیادی مصرف کند.

اگر هر دو Endpoint Rate Limit یکسان داشته باشند، کنترل مصرف منابع دقیق نخواهد بود.

بهتر است محدودیت براساس هزینه واقعی عملیات تعیین شود.

Broken Function Level Authorization چیست؟

در BFLA مشکل به سطح Function مربوط می‌شود.

فرض کنید User عادی و Admin هر دو API را استفاده می‌کنند.

Admin Endpointهایی برای:

• حذف کاربران
• مشاهده گزارش‌ها
• تغییر Role
• مدیریت تنظیمات

دارد.

اگر Backend فقط Login بودن User را بررسی کند و Role او را بررسی نکند، کنترل Function Level Authorization شکسته است.

OWASP اشاره می‌کند پیچیدگی Roleها، گروه‌ها و سلسله‌مراتب دسترسی یکی از عوامل ایجاد چنین ضعف‌هایی است.

اصل Least Privilege

هر User یا Service باید فقط حداقل دسترسی لازم برای انجام وظیفه خود را داشته باشد.

این اصل باید هم برای کاربران و هم برای Service Accountها رعایت شود.

Unrestricted Access to Sensitive Business Flows چیست؟

گاهی API از نظر فنی هیچ Bug مشخصی ندارد، اما قابلیت آن می‌تواند به‌صورت خودکار مورد سوءاستفاده قرار گیرد.

برای مثال:

• رزرو گسترده بلیت
• ایجاد انبوه حساب
• ارسال تعداد زیاد Comment
• خرید سریع موجودی محدود
• استفاده مکرر از Coupon
• جمع‌آوری گسترده اطلاعات

ممکن است تمام Requestها معتبر باشند، اما رفتار کلی برای کسب‌وکار مخرب باشد.

OWASP این موضوع را تحت API6:2023 بررسی می‌کند و تأکید دارد مشکل الزاماً ناشی از نقص برنامه‌نویسی نیست؛ گاهی Business Flow باید در برابر Automation محافظت شود.

راهکارهای دفاعی

کنترل‌هایی مانند:

• Rate Limit
• Quota
• Bot Detection
• رفتارشناسی
• CAPTCHA تطبیقی
• محدودیت Account
• تحلیل Device

می‌توانند مفید باشند.

SSRF در API چیست؟

Server-Side Request Forgery زمانی مطرح می‌شود که API براساس ورودی کاربر به یک URL یا Resource خارجی Request ارسال کند اما مقصد را به‌درستی کنترل نکند.

برای مثال یک API ممکن است قابلیتی برای دریافت تصویر از URL داشته باشد.

اگر هر مقصدی بدون Validation پذیرفته شود، سرور ممکن است درخواست‌هایی به منابعی ارسال کند که کاربر مستقیماً به آن‌ها دسترسی نداشته است.

OWASP SSRF را API7 در نسخه 2023 معرفی می‌کند و تأکید دارد مشکل زمانی ایجاد می‌شود که Resource مقصد کنترل‌شده توسط User بدون Validation مناسب دریافت شود.

روش جلوگیری از SSRF

در صورت امکان باید Destinationها Allowlist شوند.

همچنین دسترسی Network سرویس API به منابع داخلی باید براساس نیاز واقعی محدود باشد.

اصل مهم این است که Application Server نباید به تمام بخش‌های شبکه داخلی دسترسی نامحدود داشته باشد.

Security Misconfiguration در API

حتی کد امن نیز در Configuration اشتباه می‌تواند آسیب‌پذیر شود.

نمونه‌ها عبارت‌اند از:

• Debug Mode فعال
• Errorهای بسیار دقیق
• TLS نامناسب
• Endpoint مدیریتی عمومی
• CORS بیش از حد باز
• Credential پیش‌فرض
• Headerهای امنیتی ناقص
• سرویس‌های غیرضروری
• مجوزهای Cloud اشتباه

OWASP Security Misconfiguration را یکی از ده ریسک اصلی API معرفی کرده است.

CORS چیست و چه ارتباطی با API Security دارد؟

CORS یا Cross-Origin Resource Sharing مشخص می‌کند چه Originهایی اجازه دارند از مرورگر به API Request ارسال کنند و Response را بخوانند.

آیا Access-Control-Allow-Origin: * همیشه بد است؟

خیر.

برای یک Public API که هیچ Credential حساسی ندارد ممکن است مناسب باشد.

اما برای APIهای خصوصی یا مبتنی بر Cookie باید Policy دقیق متناسب با معماری تعریف شود.

نکته مهم این است که CORS جای Authentication یا Authorization را نمی‌گیرد.

حتی اگر Browser یک Request را محدود کند، مهاجم می‌تواند از Clientهای غیرمرورگری Request ایجاد کند.

Improper Inventory Management چیست؟

APIها با گذشت زمان رشد می‌کنند.

نسخه‌های جدید ایجاد می‌شوند:

/api/v1

/api/v2

و ممکن است نسخه‌های قدیمی همچنان روی Server باقی بمانند.

مشکل زمانی ایجاد می‌شود که تیم توسعه فراموش کند Endpoint قدیمی هنوز عمومی است.

OWASP مدیریت ناقص Inventory را API9:2023 معرفی می‌کند و تأکید دارد وجود نسخه‌های قدیمی، Hostهای فراموش‌شده و Endpointهای Debug می‌تواند سطح حمله را افزایش دهد.

API Inventory باید شامل چه مواردی باشد؟

حداقل:

• دامنه
• محیط
• Version
• Endpoint
• Owner
• Authentication
• سطح حساسیت
• تاریخ End-of-Life

باید مشخص باشند.

Shadow API چیست؟

Shadow API به Endpoint یا سرویسی گفته می‌شود که فعال است اما تیم امنیت یا مدیریت رسمی از آن اطلاع کاملی ندارد.

ممکن است Developer برای یک پروژه آزمایشی API ایجاد کرده باشد و سرویس بعدها فراموش شده باشد.

این Endpoint ممکن است:

• Patch نشده باشد.
• Authentication قدیمی داشته باشد.
• داده Production را نمایش دهد.
• Logging مناسبی نداشته باشد.

Inventory دقیق برای کاهش این خطر ضروری است.

Zombie API چیست؟

Zombie API معمولاً نسخه قدیمی یا منسوخ‌شده‌ای است که همچنان قابل دسترسی است.

حتی اگر Frontend جدید دیگر از آن استفاده نکند، مهاجم می‌تواند مستقیماً Request ارسال کند.

بنابراین End-of-Life API باید واقعاً غیرفعال شود، نه اینکه فقط لینک آن از رابط کاربری حذف شود.

Unsafe Consumption of APIs چیست؟

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

برای مثال:

• Payment Provider
• پیامک
• Email
• نقشه
• سیستم احراز هویت
• هوش مصنوعی
• سیستم حمل‌ونقل

یکی از اشتباهات رایج اعتماد بیش از حد به داده دریافتی از سرویس ثالث است.

OWASP API10:2023 هشدار می‌دهد که توسعه‌دهندگان گاهی داده Third-Party API را قابل اعتمادتر از User Input تلقی می‌کنند و کنترل‌های امنیتی کمتری روی آن اعمال می‌کنند.

اصل مهم

تمام داده خارجی باید غیرقابل اعتماد در نظر گرفته شود.

فرقی ندارد از:

User

Database

Webhook

Partner API

یا Service دیگر

آمده باشد.

API Key چیست؟

API Key یک مقدار شناسه یا Secret است که برای شناسایی Client یا Project استفاده می‌شود.

اما API Key همیشه جایگزین Authentication کامل کاربر نیست.

API Key را کجا ذخیره کنیم؟

API Key حساس نباید:

• داخل Repository عمومی
• JavaScript عمومی
• فایل قابل دانلود
• Log
• Screenshot
• Mobile App به‌صورت Hardcoded

قرار گیرد.

Secretهای Backend بهتر است در Secret Management مناسب نگهداری شوند.

JWT چیست؟

JWT یا JSON Web Token یکی از روش‌های رایج انتقال Claimهای Authentication و Authorization است.

JWT معمولاً شامل بخش‌هایی از اطلاعات درباره User و Token است و با Signature صحت آن بررسی می‌شود.

JWT رمزنگاری‌شده نیست مگر اینکه عمداً این کار انجام شود

یکی از سوءبرداشت‌های رایج این است که محتوای JWT به دلیل ظاهر Base64 مانند، مخفی است.

در بسیاری از JWTهای معمولی Payload قابل خواندن است.

بنابراین اطلاعات محرمانه نباید بدون نیاز داخل Token قرار گیرند.

Backend چه چیزهایی را باید بررسی کند؟

در اعتبارسنجی Token باید مواردی مانند:

• Signature
• Expiration
• Issuer
• Audience
• Algorithm Policy

براساس معماری بررسی شوند.

پذیرش Token صرفاً به دلیل اینکه Format آن شبیه JWT است اشتباه است.

OAuth 2.0 چیست؟

OAuth 2.0 چارچوبی برای Authorization است که به Client اجازه می‌دهد با مجوز مشخص به Resource دسترسی پیدا کند.

OAuth به‌تنهایی «Login Protocol» محسوب نمی‌شود؛ OpenID Connect معمولاً برای Identity روی OAuth ساخته می‌شود.

Scope در OAuth

Scope مشخص می‌کند Token چه Permissionهایی دارد.

بهتر است Tokenها Scope بسیار گسترده نداشته باشند.

اصل Least Privilege برای Tokenها نیز برقرار است.

آیا HTTPS برای امنیت API کافی است؟

خیر.

HTTPS بسیار ضروری است، زیرا از شنود و تغییر Traffic در مسیر جلوگیری می‌کند.

اما HTTPS نمی‌تواند موارد زیر را حل کند:

• Broken Authorization
• BOLA
• Authentication ضعیف
• Rate Limiting ناکافی
• SSRF
• Business Logic Abuse

HTTPS لایه حمل‌ونقل را ایمن می‌کند؛ امنیت منطق Application موضوع جداگانه‌ای است.

OWASP در REST Security نیز استفاده از HTTPS را از الزامات پایه ارتباط امن API می‌داند.

اعتبارسنجی ورودی در API

API نباید فرض کند چون Client رسمی خودش Request را می‌سازد، داده ورودی همیشه معتبر است.

هر Request می‌تواند خارج از برنامه رسمی ساخته شود.

چه مواردی باید Validate شوند؟

• نوع داده
• طول
• محدوده
• Format
• مقدار مجاز
• تعداد عناصر
• اندازه Request

برای مثال اگر فیلد Age باید عددی بین محدوده مشخص باشد، Backend باید همان Policy را اعمال کند.

Validation سمت Frontend فقط برای تجربه کاربری است.

استفاده از Schema Validation

برای JSON API می‌توان Schema مشخص تعریف کرد.

Schema می‌تواند تعیین کند:

کدام فیلدها Required هستند؟

نوع هر فیلد چیست؟

حداکثر طول چقدر است؟

آیا Property اضافه قابل قبول است؟

این کار باعث می‌شود Requestهای غیرمنتظره زودتر Reject شوند.

جلوگیری از Injection در API

داده API ممکن است در Database، Shell، Template یا سیستم دیگری استفاده شود.

اصل کلی این است:

داده User نباید به‌عنوان دستور تفسیر شود.

برای Database باید از Queryهای Parameterized یا روش‌های امن ORM استفاده شود.

Filtering چند کلمه خاص راهکار مطمئنی برای Injection نیست.

امنیت REST API

REST یکی از رایج‌ترین سبک‌های طراحی API است و معمولاً از HTTP و Resourceهای دارای URI استفاده می‌کند. OWASP REST Security Cheat Sheet مجموعه‌ای از توصیه‌های امنیتی برای چنین APIهایی ارائه می‌کند.

استفاده صحیح از HTTP Method

روش‌هایی مانند:

GET

POST

PUT

PATCH

DELETE

باید متناسب با عملیات واقعی استفاده شوند.

همچنین Backend باید Methodهای غیرمجاز را Reject کند.

اطلاعات حساس در URL قرار ندهید

URL ممکن است در:

• Log
• History
• Proxy
• Analytics

ثبت شود.

بنابراین اطلاعاتی مانند Password یا Token حساس بهتر است در Query String قرار نگیرند.

امنیت GraphQL API

GraphQL انعطاف زیادی به Client می‌دهد و همین موضوع به کنترل‌های خاص نیاز دارد.

Authorization در GraphQL

وجود یک Endpoint واحد مانند /graphql باعث نمی‌شود Authorization ساده‌تر شود.

Resolverهای مختلف همچنان باید Permission مناسب را بررسی کنند.

محدود کردن Query Complexity

Client می‌تواند Queryهای پیچیده ایجاد کند.

اگر هیچ محدودیتی وجود نداشته باشد، Query بسیار عمیق یا سنگین می‌تواند منابع Backend را مصرف کند.

می‌توان محدودیت‌هایی برای:

• Depth
• Complexity
• Timeout
• تعداد Object

تعریف کرد.

غیرفعال کردن ابزارهای توسعه در Production در صورت عدم نیاز

قابلیت‌های توسعه‌ای و Debug باید براساس نیاز واقعی Production مدیریت شوند.

امنیت API موبایل

یکی از اصول مهم این است:

اپلیکیشن موبایل محیط امن برای نگهداری Secret مشترک نیست.

فایل برنامه روی دستگاه User قرار دارد و نباید امنیت Backend به مخفی ماندن یک مقدار Hardcoded وابسته باشد.

Backend باید Client را غیرقابل اعتماد فرض کند

حتی اگر App رسمی فقط دکمه‌های مشخصی دارد، API باید فرض کند Request می‌تواند به‌صورت دستی ساخته شود.

امنیت API در وردپرس

وردپرس REST API و همچنین Endpointهای مختلفی از طریق Pluginها ارائه می‌دهد.

وجود REST API به‌خودی‌خود مشکل امنیتی نیست.

خطر زمانی ایجاد می‌شود که Plugin یا کد اختصاصی Endpointی ایجاد کند و:

• Permission Callback مناسب نداشته باشد.
• ورودی را Validate نکند.
• Output بیش از حد برگرداند.
• نقش کاربر را بررسی نکند.

افزونه‌های وردپرس

هر Plugin ممکن است Endpoint جدیدی اضافه کند.

به همین دلیل به‌روزرسانی و حذف Pluginهای بلااستفاده اهمیت زیادی دارد.

Webhook Security چیست؟

Webhook حالتی است که یک سرویس خارجی به API سایت شما Request ارسال می‌کند.

برای مثال درگاه پرداخت پس از تراکنش Callback ارسال می‌کند.

فقط IP را معیار اعتماد قرار ندهید

بسته به Provider می‌توان از Signature Request، Secret و Timestamp برای اعتبارسنجی اصالت پیام استفاده کرد.

همچنین عملیات Webhook باید Idempotent باشد تا ارسال مجدد همان Event باعث اجرای چندباره عملیات حساس نشود.

Idempotency چیست؟

Idempotency یعنی تکرار یک Request مشخص نتیجه ناخواسته تکراری ایجاد نکند.

این موضوع برای APIهای:

• پرداخت
• سفارش
• انتقال
• Callback

بسیار مهم است.

یک Client ممکن است به دلیل Timeout Request را دوباره ارسال کند.

Backend باید بتواند تشخیص دهد عملیات قبلاً پردازش شده است.

مدیریت خطا در API

Error Response نباید اطلاعات داخلی غیرضروری افشا کند.

پیام‌هایی مانند:

• Stack Trace
• Database Query
• مسیر فایل
• Secret
• Configuration

نباید برای Client عمومی ارسال شوند.

در سمت Server می‌توان جزئیات لازم را Log کرد، اما Response عمومی باید کنترل‌شده باشد.

Logging در امنیت API

بدون Log مناسب، تشخیص بسیاری از حملات دشوار می‌شود.

چه رویدادهایی مهم هستند؟

• Login Failure
• Authorization Failure
• Rate Limit Event
• تغییر Permission
• ایجاد API Key
• حذف Token
• خطاهای حساس
• Requestهای غیرعادی
• عملیات مدیریتی

چه چیزهایی نباید Log شوند؟

از ثبت مستقیم موارد زیر خودداری شود:

• Password
• Token کامل
• Secret
• اطلاعات کارت
• Credential

Log امنیتی نباید خودش به منبع نشت اطلاعات تبدیل شود.

Monitoring و Alerting

داشتن Log کافی نیست.

برای رویدادهای مهم باید Alert مناسب ایجاد شود.

برای مثال:

تعداد بالای 401

افزایش 403

افزایش Request Rate

استفاده غیرعادی یک API Key

خطای زیاد روی Endpoint حساس

تغییر ناگهانی الگوی Traffic

می‌توانند علامت رفتار مشکوک باشند.

API Gateway چیست؟

API Gateway می‌تواند یک نقطه مرکزی برای مدیریت ترافیک API باشد.

قابلیت‌های احتمالی آن شامل:

• Authentication
• Rate Limiting
• Routing
• Logging
• Quota
• Transformation
• Monitoring

است.

اما Gateway نباید باعث شود Developer تصور کند Authorization داخل Application دیگر لازم نیست.

کنترل Business Permission معمولاً باید در خود Backend نیز وجود داشته باشد.

WAF برای API چه کاربردی دارد؟

Web Application Firewall می‌تواند برخی Requestهای مخرب را قبل از رسیدن به Backend متوقف کند.

WAF برای:

• الگوهای شناخته‌شده
• Rate Control
• Bot Management
• Reputation

مفید است.

اما BOLA یا Business Logic Abuse را همیشه نمی‌تواند تشخیص دهد.

بنابراین WAF مکمل Secure Coding است.

Zero Trust در API Security

یکی از اصول Zero Trust این است که اعتماد صرفاً به دلیل Location شبکه داده نشود.

API داخلی نیز ممکن است در معرض Compromise قرار گیرد.

Serviceهای داخلی باید براساس هویت و Permission مشخص با یکدیگر ارتباط داشته باشند.

قرار داشتن در «شبکه داخلی» نباید به معنی دسترسی نامحدود باشد.

امنیت Microservice APIها

در معماری Microservice، API فقط برای User نهایی نیست.

سرویس‌ها نیز با یکدیگر ارتباط دارند.

Service-to-Service Authentication

هر Service باید هویت مشخصی داشته باشد.

Credentialهای مشترک و دائمی میان تعداد زیادی Service ریسک بالایی دارند.

Network Segmentation

هر Service فقط باید به Serviceهایی دسترسی Network داشته باشد که واقعاً نیاز دارد.

این موضوع اثر Compromise یک سرویس را محدود می‌کند.

Secret Management

Secretها شامل:

• API Key
• Database Password
• Signing Key
• Service Credential

هستند.

این مقادیر باید چرخه عمر مشخص داشته باشند.

Rotation

Secret حساس باید قابلیت Rotation داشته باشد.

اگر Credential افشا شد، تیم نباید برای تغییر آن نیازمند تغییر گسترده کد باشد.

Versioning در API Security

Versioning فقط مسئله توسعه نرم‌افزار نیست؛ مسئله امنیتی نیز هست.

نسخه‌های قدیمی ممکن است:

• Library قدیمی داشته باشند.
• Authentication ضعیف‌تری داشته باشند.
• Patchهای جدید را دریافت نکنند.

برای هر نسخه باید End-of-Life مشخص وجود داشته باشد.

API Documentation و امنیت

مستندات دقیق به تیم توسعه و امنیت کمک می‌کنند بفهمند چه Endpointهایی باید وجود داشته باشند.

اما Documentation عمومی نباید Secret واقعی یا Credential Production داشته باشد.

نمونه Requestها باید از داده Test استفاده کنند.

تست امنیت API

تست امنیت باید تنها روی APIهایی انجام شود که مالک آن هستید یا مجوز رسمی ارزیابی آن‌ها را دارید.

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

• Authentication
• Authorization
• Object Permission
• Function Permission
• Rate Limiting
• Input Validation
• Error Handling
• CORS
• Token Handling
• Resource Consumption
• API Inventory
• Business Logic

تست BOLA چگونه باید در سطح دفاعی بررسی شود؟

هدف تست این است که مشخص شود Userهای مختلف تنها به Objectهای مجاز خود دسترسی دارند.

برای این کار بهتر است حساب‌های Test با Roleهای مختلف در اختیار تیم امنیت قرار گیرند.

تمام عملیات Read، Update و Delete باید از نظر Object-Level Authorization بررسی شوند.

تست Roleهای مختلف

یک API ممکن است نقش‌های زیر داشته باشد:

• User
• Seller
• Support
• Manager
• Administrator

نباید فقط User ناشناس آزمایش شود.

بخش بزرگی از ضعف‌های Authorization زمانی مشخص می‌شوند که Permission دو Role با یکدیگر مقایسه شوند.

SAST، DAST و تست دستی API

هیچ‌کدام به‌تنهایی کامل نیستند.

SAST

کد را تحلیل می‌کند و می‌تواند برخی Patternهای ناامن را پیدا کند.

DAST

API اجراشده را از بیرون بررسی می‌کند.

تست دستی

برای Authorization و Business Logic اهمیت زیادی دارد.

ترکیب این روش‌ها Coverage بیشتری ایجاد می‌کند.

چرا Scanner به‌تنهایی امنیت API را تضمین نمی‌کند؟

Scanner معمولاً نمی‌داند Business Rule برنامه چیست.

برای مثال ابزار از کجا باید بداند فروشنده فقط اجازه مشاهده سفارش‌های فروشگاه خودش را دارد؟

این Context باید توسط متخصص یا تست‌های اختصاصی Authorization بررسی شود.

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

بهترین زمان برای حل آسیب‌پذیری قبل از Production است.

مرحله طراحی

Threat Model تهیه شود.

داده‌های حساس، Trust Boundaryها و Roleها مشخص شوند.

مرحله توسعه

Secure Coding و Libraryهای استاندارد استفاده شوند.

Code Review

Endpointهای جدید از نظر Authentication و Authorization بررسی شوند.

CI/CD

تست‌های Security و Dependency Scan اجرا شوند.

Production

Monitoring و Alerting ادامه پیدا کنند.

Threat Modeling برای API

قبل از نوشتن کد بهتر است چند سؤال مطرح شود:

چه کسی می‌تواند این Endpoint را فراخوانی کند؟

چه اطلاعاتی دریافت می‌کند؟

چه اطلاعاتی تغییر می‌دهد؟

اگر Request هزار بار اجرا شود چه می‌شود؟

اگر User ID تغییر کند چه می‌شود؟

اگر Service ثالث داده غیرمنتظره برگرداند چه می‌شود؟

این پرسش‌ها بسیاری از مشکلات طراحی را قبل از تبدیل شدن به Bug آشکار می‌کنند.

چک‌لیست افزایش امنیت API

برای بررسی اولیه API می‌توان این موارد را کنترل کرد:

• تمام APIها فقط روی HTTPS ارائه شوند.
• Authentication استاندارد استفاده شود.
• Authorization در Backend اجرا شود.
• هر Object دارای کنترل دسترسی مستقل باشد.
• Functionهای مدیریتی Role Check داشته باشند.
• Propertyهای قابل خواندن و تغییر Allowlist شوند.
• Rate Limiting تعریف شود.
• Endpointهای پرهزینه محدودیت مستقل داشته باشند.
• Request Size محدود شود.
• Input Validation سمت Server انجام شود.
• Queryهای Database Parameterized باشند.
• Errorها اطلاعات داخلی افشا نکنند.
• Tokenها عمر مناسب داشته باشند.
• Secretها داخل Repository ذخیره نشوند.
• API Keyها قابلیت Rotation داشته باشند.
• CORS براساس نیاز واقعی تنظیم شود.
• Endpointهای قدیمی حذف شوند.
• Inventory کامل API نگهداری شود.
• Shadow APIها شناسایی شوند.
• Third-Party API Data غیرقابل اعتماد فرض شود.
• Webhookها اعتبارسنجی شوند.
• عملیات حساس Idempotency مناسب داشته باشند.
• رویدادهای امنیتی Log شوند.
• Alert برای رفتار مشکوک وجود داشته باشد.
• Backup و Incident Response تعریف شوند.
• تست امنیت دوره‌ای انجام شود.

نشانه‌های احتمالی حمله به API

وجود یک علامت به‌تنهایی اثبات حمله نیست، اما ترکیب چند مورد می‌تواند مهم باشد.

افزایش خطاهای Authorization

افزایش شدید 401 یا 403 می‌تواند نشان‌دهنده تلاش برای دسترسی غیرمجاز باشد.

Request Rate غیرعادی

یک Client که ناگهان هزاران Request ایجاد می‌کند باید بررسی شود.

دسترسی ترتیبی به Resourceهای متعدد

رفتار غیرعادی در مشاهده تعداد زیادی Object می‌تواند نشانه Scraping یا تلاش برای سوءاستفاده از Authorization باشد.

مصرف شدید Endpoint خاص

افزایش Load فقط روی Search یا Export می‌تواند نشانه Resource Abuse باشد.

استفاده از API قدیمی

Traffic ناگهانی روی نسخه‌ای که Client رسمی دیگر استفاده نمی‌کند باید بررسی شود.

اگر API هک شد چه کار کنیم؟

واکنش باید براساس Incident Response Plan انجام شود.

دسترسی مهاجم را محدود کنید

Token، API Key یا Sessionهای مشکوک در صورت لزوم باطل شوند.

Logها حفظ شوند

Evidence برای تحلیل Incident اهمیت دارد.

Scope حادثه مشخص شود

آیا یک User تحت تأثیر بوده یا کل API؟

آیا اطلاعات مشاهده شده‌اند یا تغییر کرده‌اند؟

Credentialها Rotate شوند

اگر احتمال افشای Secret وجود دارد، Credential مرتبط باید تعویض شود.

Root Cause اصلاح شود

مسدود کردن یک IP مشکل Authorization را حل نمی‌کند.

اگر دلیل حادثه BOLA بوده است، کنترل دسترسی باید در همه Endpointهای مشابه بررسی شود.

Retest انجام شود

بعد از Patch باید مطمئن شد مشکل واقعاً حل شده و مسیر دیگری باقی نمانده است.

مهم‌ترین اشتباهات در امنیت API

اعتماد به Frontend

Client را نمی‌توان کنترل امنیتی در نظر گرفت.

فرض امن بودن UUID

شناسه تصادفی جای Authorization را نمی‌گیرد.

استفاده از یک API Key دائمی

Credential بدون Rotation ریسک Incident را افزایش می‌دهد.

ارسال اطلاعات بیش از حد

Response باید فقط داده لازم را برگرداند.

نبود Rate Limit

حتی Endpoint بدون Bug می‌تواند مورد Abuse قرار گیرد.

نگه داشتن نسخه‌های قدیمی

Zombie APIها یکی از منابع مهم Attack Surface هستند.

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

Third-Party Response نیز باید Validate شود.

لاگ کردن Token

Log نباید Secret Store ناخواسته ایجاد کند.

استفاده از WAF به‌عنوان تنها دفاع

WAF نمی‌تواند جای Business Authorization را بگیرد.

معماری امن API چگونه طراحی می‌شود؟

یک معماری ساده چندلایه می‌تواند چنین باشد:

Client → CDN/Edge → WAF → API Gateway → Authentication → Authorization → Application → Database

اما وجود این لایه‌ها به‌تنهایی امنیت ایجاد نمی‌کند.

در هر مرحله باید Control مشخصی وجود داشته باشد.

Edge ترافیک غیرعادی را مدیریت می‌کند.

Gateway Rate Limit و Routing را انجام می‌دهد.

Authentication هویت را مشخص می‌کند.

Authorization Permission را بررسی می‌کند.

Application Business Rule را اعمال می‌کند.

Database نیز باید با Credential محدود در دسترس باشد.

Defense in Depth در API

امنیت چندلایه باعث می‌شود شکست یک کنترل به معنی شکست کامل سیستم نباشد.

فرض کنید API Key یک Client افشا شده است.

Rate Limit می‌تواند Abuse را محدود کند.

Authorization مانع دسترسی به Resourceهای غیرمجاز می‌شود.

Monitoring رفتار غیرعادی را تشخیص می‌دهد.

Alert تیم امنیت را مطلع می‌کند.

Secret Rotation Credential را باطل می‌کند.

ترکیب این کنترل‌ها اثر Incident را کاهش می‌دهد.

آیا API خصوصی نیاز به امنیت دارد؟

بله.

Internal API نیز می‌تواند از طریق:

• Account Compromise
• SSRF
• Misconfiguration
• Insider Threat
• سرویس آلوده

هدف قرار گیرد.

نباید امنیت API را فقط براساس قابل مشاهده بودن آن از اینترنت تعیین کرد.

آیا مخفی کردن Endpoint امنیت ایجاد می‌کند؟

خیر.

نام عجیب Endpoint یا نبود Documentation عمومی می‌تواند کشف اتفاقی را کاهش دهد، اما کنترل امنیتی محسوب نمی‌شود.

اصل Kerckhoffs در امنیت یادآوری می‌کند که امنیت سیستم نباید به مخفی ماندن طراحی آن وابسته باشد.

API باید حتی در صورت شناخته شدن تمام Endpointها امن بماند.

آیا API Key در URL قرار بگیرد؟

بهتر است Secretها در URL قرار نگیرند.

URLها ممکن است در Log، History یا ابزارهای Analytics ثبت شوند.

Credential باید از مکانیزم استاندارد Header یا روش توصیه‌شده معماری استفاده کند.

آیا JWT بهتر از Session است؟

پاسخ مطلق وجود ندارد.

JWT و Server-Side Session هرکدام مزایا و محدودیت‌هایی دارند.

امنیت بیشتر به Implementation بستگی دارد تا نام تکنولوژی.

Token بدون Expiration مناسب یا Session بدون کنترل نیز می‌توانند مشکل‌ساز باشند.

آیا امنیت API فقط مسئولیت Backend Developer است؟

خیر.

API Security یک مسئولیت مشترک است.

معمار سیستم باید Trust Boundaryها را درست طراحی کند.

Backend Developer کنترل‌ها را پیاده‌سازی کند.

DevOps Secret و Infrastructure را ایمن کند.

Frontend Token را درست مدیریت کند.

تیم امنیت تست و Monitoring را انجام دهد.

Product Manager نیز Business Abuse را در نظر بگیرد.

سوالات متداول درباره امنیت API

امنیت API چیست؟

امنیت API مجموعه کنترل‌هایی برای محافظت از Endpointها، داده‌ها و عملیات API در برابر دسترسی غیرمجاز، سوءاستفاده، افشای اطلاعات و مصرف غیرعادی منابع است.

مهم‌ترین آسیب‌پذیری API چیست؟

نوع ریسک به معماری بستگی دارد، اما Broken Object Level Authorization یا BOLA یکی از شناخته‌شده‌ترین و مهم‌ترین مشکلات API است و در OWASP API Security Top 10 2023 در رتبه نخست قرار دارد.

آیا HTTPS API را امن می‌کند؟

HTTPS ارتباط را در مسیر محافظت می‌کند، اما مشکلاتی مانند BOLA، Broken Authentication یا Business Logic Abuse را برطرف نمی‌کند.

API Key و JWT چه تفاوتی دارند؟

API Key معمولاً Client یا Application را شناسایی می‌کند، در حالی که JWT می‌تواند Claimهای هویت و Authorization را منتقل کند. نحوه استفاده به معماری بستگی دارد.

آیا API بدون Login امن است؟

Public API نیز باید در برابر Resource Abuse، Injection، Data Exposure و سایر ریسک‌ها محافظت شود. نبود Login به معنی نبود نیاز امنیتی نیست.

آیا CORS جلوی هک API را می‌گیرد؟

خیر. CORS یک Policy مرورگر است و جای Authentication و Authorization را نمی‌گیرد.

Rate Limiting چرا مهم است؟

Rate Limiting مانع مصرف نامحدود Resource می‌شود و می‌تواند اثر Brute Force، Scraping، Bot Abuse و Application DoS را کاهش دهد.

آیا UUID جلوی BOLA را می‌گیرد؟

خیر. UUID فقط Predictability شناسه را کاهش می‌دهد. Backend باید همچنان Permission کاربر روی Object را بررسی کند.

آیا REST API امن‌تر از GraphQL است؟

هیچ‌کدام ذاتاً امن‌تر نیستند. امنیت به طراحی و پیاده‌سازی بستگی دارد. GraphQL و REST هرکدام نیازهای امنیتی خاص خود را دارند.

آیا WAF برای امنیت API کافی است؟

خیر. WAF یک لایه مکمل است. ضعف‌های Authorization و Business Logic باید در Application اصلاح شوند.

هر چند وقت یک بار API باید تست امنیتی شود؟

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

جمع‌بندی

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

مهم‌ترین نکته این است که API را نباید صرفاً یک کانال انتقال داده دانست. API مرز دسترسی به Business Logic و Resourceهای سیستم است و تمام Requestهای آن باید براساس اصل «Never Trust the Client» بررسی شوند.

Authentication تنها مرحله اول است. پس از مشخص شدن هویت، Backend باید برای هر Function، Object و Property بررسی کند که User دقیقاً چه Permissionهایی دارد.

OWASP نیز Authorization را همچنان یکی از بزرگ‌ترین چالش‌های API Security معرفی می‌کند و Broken Object Level Authorization را در صدر فهرست API Security Top 10 2023 قرار داده است.

علاوه بر کنترل دسترسی، Resource Consumption باید محدود شود. Rate Limiting، Request Size Limit، Quota و کنترل Endpointهای پرهزینه باعث می‌شوند یک Client نتواند منابع Application یا هزینه سرویس‌های جانبی را بدون محدودیت مصرف کند.

Security Misconfiguration، SSRF، نسخه‌های فراموش‌شده API و اعتماد بیش از حد به Third-Party Serviceها نیز باید جدی گرفته شوند. Inventory دقیق و حذف Zombie APIها بخش مهمی از مدیریت Attack Surface است.

HTTPS باید برای تمام APIهای حساس استفاده شود، اما HTTPS به‌تنهایی امنیت API نیست. API Key، JWT، OAuth، WAF و API Gateway نیز ابزار هستند و هیچ‌کدام جای Authorization درست و Secure Coding را نمی‌گیرند.

در سطح معماری، بهترین رویکرد استفاده از Defense in Depth است. Edge و WAF ترافیک مشکوک را کاهش می‌دهند، API Gateway محدودیت و Routing را مدیریت می‌کند، Authentication هویت را بررسی می‌کند، Authorization دسترسی را کنترل می‌کند و Application Business Rule را اعمال می‌کند.

Logging و Monitoring نیز باید بخشی از طراحی اولیه باشند. بدون Visibility مناسب ممکن است سوءاستفاده از API هفته‌ها ادامه پیدا کند بدون اینکه تیم فنی متوجه شود.

برای سایت‌های وردپرسی نیز REST API و Endpointهای ایجادشده توسط Pluginها باید مانند هر API دیگری بررسی شوند. فعال بودن API به‌خودی‌خود آسیب‌پذیری نیست؛ مشکل زمانی ایجاد می‌شود که Endpoint بدون Permission Check، Validation یا محدودیت مناسب توسعه داده شود.

در نهایت، امنیت API یک محصول یا تنظیم یک‌باره نیست. هر Endpoint جدید، Integration جدید، نسخه جدید و Business Flow تازه می‌تواند Attack Surface را تغییر دهد.

بهترین راه برای جلوگیری از هک API این است که امنیت از مرحله طراحی وارد پروژه شود، Roleها و Resourceها از ابتدا مشخص باشند، کنترل‌های Authorization قابل تست نوشته شوند، API Inventory همیشه به‌روز بماند و تست‌های امنیتی بخشی از CI/CD و نگهداری مداوم سیستم باشند.

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