چک‌لیست امنیت API در ۲۰۲۷: قبل از اتصال هر سرویس خارجی این‌ها را بررسی کنید

چرا API نقطه‌ی ضعف اصلی شده است

پاسخ کوتاه: امروز بیشتر رخنه‌های نرم‌افزاری از سمت API اتفاق می‌افتد، نه از رابط کاربری؛ چون API مستقیم به داده وصل است و اغلب کمتر از صفحات وب تست می‌شود. مهم‌ترین موارد چک‌لیست عبارت‌اند از کنترل دسترسی سطح شیء (BOLA)، احراز هویت درست، محدودسازی نرخ درخواست، اعتبارسنجی ورودی، مدیریت امن کلیدها و لاگ‌برداری بدون داده‌ی حساس. رعایت همین شش مورد جلوی اکثر حمله‌های واقعی را می‌گیرد.

فهرست OWASP API Top 10 هم سال‌هاست همین الگو را نشان می‌دهد: مشکلات اصلی منطقی و مربوط به مجوز دسترسی‌اند، نه آسیب‌پذیری‌های عجیب و پیچیده.

احراز هویت و کنترل دسترسی

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

شایع‌ترین اشتباه این است که سرویس فقط چک می‌کند «کاربر لاگین کرده؟» ولی بررسی نمی‌کند «این کاربر مالک این رکورد هست؟». تغییر یک شناسه در آدرس درخواست نباید داده‌ی کاربر دیگری را برگرداند.

• بررسی مالکیت رکورد در هر درخواست، نه فقط در رابط کاربری
• توکن با عمر کوتاه و مکانیزم تازه‌سازی امن
• تفکیک نقش‌ها در سمت سرور و ذخیره‌ی نقش در جدول مستقل
• غیرفعال‌کردن فوری توکن پس از خروج یا تغییر رمز

ورودی، خروجی و محدودسازی نرخ

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

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

محدودسازی نرخ درخواست (Rate Limiting) هم برای جلوگیری از حمله‌ی brute force ضروری است و هم برای مهار هزینه، مخصوصاً وقتی API شما به سرویس پولی مثل مدل‌های زبانی وصل است.

• اعتبارسنجی ورودی با اسکیمای صریح در سمت سرور
• محدودکردن اندازه‌ی درخواست و تعداد آیتم‌های صفحه‌بندی
• Rate limit به‌ازای کاربر و به‌ازای IP
• بازگرداندن پیام خطای عمومی بدون افشای جزئیات داخلی

کلیدها، اسرار و سرویس‌های شخص ثالث

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

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

قبل از اتصال هر سرویس خارجی، سه چیز را بررسی کنید: چه داده‌ای از کاربران شما نزد آن سرویس می‌رود، آیا وب‌هوک‌هایش امضای قابل‌راستی‌آزمایی دارند، و در صورت قطع شدن سرویس چه اتفاقی برای جریان کاری شما می‌افتد.

لاگ، پایش و آزمون دوره‌ای

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

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

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