یکی از پروژه‌ها را به‌خاطر می‌آورم که در آن، فرانت‌اند و بک‌اند از هم جدا بودند و همه‌چیز تمیز و مدرن به‌نظر می‌رسید. تا این‌که یک محقق امنیتی، در ازای پرداخت یک مبلغ ناچیز، تمام تراکنش‌های کاربران را از طریق یک endpoint بدون احراز هویت خواند. آن پروژه به من یاد داد امنیت API (Application Programming Interface) ماجرای جداگانه‌ای از امنیت وب‌سایت است؛ حتی اگر هر دو روی یک زیرساخت اجرا شوند.

در این مقاله، چارچوبی که در پروژه‌های واقعی برای حفاظت از API به‌کار می‌برم را گام‌به‌گام می‌گویم: از احراز هویت و مجوزدهی، تا Rate Limiting، مدیریت کلیدها و دفاع در برابر حملات رایج OWASP API Top 10. اگر تازه با مفهوم API آشنا می‌شوید، پیشنهاد می‌کنم ابتدا API چیست و چه کاربردی دارد؟ را بخوانید تا زمینه لازم را داشته باشید.

امنیت API دقیقاً چه معنایی دارد؟

امنیت API (API Security) مجموعه‌ای از اقدامات فنی، معماری و فرآیندی است که تضمین می‌کند فقط درخواست‌های مجاز، از طرف کاربران مجاز، به داده‌های درست دسترسی پیدا می‌کنند و پاسخ‌های API، داده‌های حساس را لو نمی‌دهند. اگر ساده بخواهم بگویم، امنیت API به سه سوال پاسخ می‌دهد:

  • شما کی هستید؟ (Authentication / احراز هویت)
  • چه اجازه‌ای دارید؟ (Authorization / مجوزدهی)
  • درخواست شما قابل اعتماد است؟ (Input Validation و Integrity)

نکته‌ای که در پروژه‌های واقعی بارها دیده‌ام این است که تیم‌ها یک یا دو مورد اول را حل می‌کنند و مورد سوم را کاملاً فراموش می‌کنند. نتیجه‌اش یک API است که در ظاهر امن به‌نظر می‌رسد، ولی یک Payload مخرب می‌تواند کل دیتابیس را در معرض دید قرار دهد. برای درک بهتر مفاهیم پایه، مقاله امنیت وب چیست؟ دید خوبی از لایه‌های کلی امنیت به شما می‌دهد.

معماری امنیتی API را می‌توان به لایه‌های زیر تقسیم کرد: لایه انتقال (TLS)، لایه احراز هویت، لایه مجوزدهی، لایه اعتبارسنجی داده، لایه محدودسازی نرخ، لایه پایش و لاگ، و در نهایت لایه مدیریت رمز و کلید. هر لایه باید مستقل قابل بررسی باشد؛ اگر یک لایه ضعیف باشد، کل زنجیره امنیتی به همان اندازه ضعیف است.

چرا امنیت API از امنیت وب‌سایت پیچیده‌تر است؟

در وب‌سایت معمولی، بازدیدکننده فقط با مرورگر و کدهای HTML/CSS/JS مواجه است. ولی API کانال‌های متعددی دارد: موبایل‌اپلیکیشن، SPAs (Single Page Applications)، سیستم‌های همکار، افزونه‌های مرورگر، ربات‌های اتوماسیون، سرویس‌های داخلی و حتی اسکریپت‌های مهاجم. هر کدام از این کانال‌ها، سطح حمله جداگانه‌ای ایجاد می‌کند.

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

  • بدون CSRF Token سنتی: APIها معمولاً token-based هستند، پس قواعد سنتی CSRF پاسخ نمی‌دهد
  • بدون Same-Origin Policy: درخواست‌ها می‌توانند از هر دامنه‌ای بیایند؛ CORS باید دقیق تنظیم شود
  • داده‌های بیشتر، حساس‌تر: API اغلب به داده‌های ساختاریافته و مستقیم دسترسی دارد
  • ناشناس بودن ترافیک: کاربر نمی‌تواند ببیند چه چیزی از دستگاهش ارسال می‌شود
  • Endpointهای متعدد: یک API مدرن می‌تواند صدها endpoint داشته باشد؛ هر کدام یک نقطه ضعف بالقوه

به همین دلیل، در سال‌های اخیر OWASP فهرست جداگانه‌ای به‌نام OWASP API Security Top 10 منتشر کرده که ده ریسک اصلی API را شناسایی می‌کند. این فهرست اکنون مرجع اصلی تیم‌های امنیتی در ارزیابی API است.

APIها نیمه پنهانِ اپلیکیشن‌ها هستند؛ هرچه فرانت‌اند تمیزتر و مدرن‌تر باشد، احتمال این‌که امنیت به فراموشی سپرده شود بیشتر است.

نقشه تهدید: APIها چطور هدف گرفته می‌شوند؟

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

دسته حملهنمونه واقعیلایه دفاعی اصلی
Broken Object Level Authorizationتغییر ID در URL و دسترسی به داده کاربران دیگرمجوزدهی در سطح منبع
Broken User Authenticationتوکن‌های بی‌انقضا یا ضعیفاحراز هویت مستحکم
Excessive Data Exposureارسال تمام فیلدهای کاربر در پاسخ APIفیلتر خروجی (DTO)
Lack of Resources & Rate Limitingحمله Brute Force روی endpoint ورودRate Limiting و CAPTCHA
Mass Assignmentارسال فیلدهای اضافه که به دیتابیس ذخیره می‌شودWhitelist فیلدها
InjectionSQL، NoSQL، Command Injection در پارامترهاParameterized Query و اعتبارسنجی
Security Misconfigurationفعال بودن CORS گسترده یا Debug Modeسخت‌سازی محیط

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

احراز هویت API — انتخاب درست، نیمه امنیت است

انتخاب روش احراز هویت، پایه کل امنیت API شماست. در پروژه‌های واقعی، چهار روش اصلی دیده‌ام که هرکدام برای سناریوی خاصی مناسب است:

API Key

یک رشته تصادفی طولانی که کلاینت در هدر ارسال می‌کند. مناسب برای احراز هویت سرویس‌به‌سرویس (Server-to-Server) که در آن، کاربر انسانی درگیر نیست. برخلاف تصور رایج، API Key به‌تنهایی احراز هویت نیست؛ بیشتر یک شناسه است. اگر لو برود، هیچ لایه اضافه‌ای برای حفاظت وجود ندارد.

JWT (JSON Web Token)

توکن‌های امضاشده که خودشان حاوی اطلاعات کاربر هستند. رایج‌ترین روش امروز، مخصوصاً در SPAها و اپلیکیشن‌های موبایل. مهم‌ترین نکته امنیتی: امضا (Signature) باید حتماً بررسی شود و طول عمر توکن (Expiration) کوتاه باشد. جزئیات کامل را در JWT چیست و چه کاربردی در احراز هویت دارد؟ باز کرده‌ام.

OAuth 2.0 و OpenID Connect

استانداردی برای واگذاری دسترسی محدود به شخص ثالث. اگر می‌خواهید کاربر با حساب گوگل یا گیت‌هاب وارد شود، یا می‌خواهید API شما به سرویس دیگری دسترسی داشته باشد، OAuth انتخاب درست است. توضیح مکانیزم را در OAuth چیست و چگونه کار می‌کند؟ آورده‌ام.

mTLS (Mutual TLS)

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

مقایسه دقیق‌تر این روش‌ها را در بهترین روش‌های احراز هویت کاربران کدامند؟ آورده‌ام. انتخاب بین این روش‌ها، به سناریوی دقیق شما بستگی دارد؛ انتخاب یک روش بدون درک سناریو، رایج‌ترین اشتباه این حوزه است.

یک نکته‌ای که در تحلیل‌های امنیتی مهم است: هر روش احراز هویت، به‌تنهایی فقط نیمی از داستان است. مهم‌تر از انتخاب روش، پیاده‌سازی درست آن است. برای مثال، JWT امضاشده با الگوریتم ضعیف، از یک API Key ساده امن‌تر نیست.

مجوزدهی — جایی که بیشتر APIها می‌شکنند

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

RBAC (Role-Based Access Control)

دسترسی بر اساس نقش کاربر. مثلاً ادمین، ویرایشگر، نویسنده. ساده، قابل درک، ولی در سیستم‌های پیچیده به دیوار می‌خورد. اگر نقش‌ها زیاد شوند، ماتریس دسترسی به یک هزارتو تبدیل می‌شود.

ABAC (Attribute-Based Access Control)

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

مجوزدهی در سطح منبع

مهم‌ترین لایه‌ای که در APIها فراموش می‌شود. هر endpoint که به یک منبع مشخص دسترسی دارد، باید مطمئن شود که کاربر درخواست‌کننده، واقعاً مالک آن منبع است. مثال کلاسیک: endpoint زیر را در نظر بگیرید:

GET /api/orders/12345

اگر فقط احراز هویت را چک کنید، هر کاربر احراز‌شده‌ای می‌تواند با تغییر `12345` به `12346`، سفارش کاربر دیگری را ببیند. این آسیب‌پذیری که IDOR (Insecure Direct Object Reference) نام دارد، یکی از رایج‌ترین حفره‌های API است و در OWASP API Top 10، رتبه اول را دارد. روش دفاع در آسیب‌پذیری IDOR چیست و چگونه رفع می‌شود؟ آمده است.

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

مجوزدهی، فقط پاسخ دادن به این سوال نیست که «آیا این کاربر اجازه دارد؟»؛ باید بپرسد «آیا این کاربر روی این منبع مشخص اجازه دارد؟».

اعتبارسنجی ورودی و پاک‌سازی داده

هر داده‌ای که از کلاینت می‌آید، باید بدترین فرض را داشته باشد. این اصل ساده، پایه دفاع در برابر Injectionها است. سه لایه اعتبارسنجی که در پروژه‌ها اجرا می‌کنم:

اعتبارسنجی ساختاری

پارامترها باید با Schema مشخصی مطابقت داشته باشند: نوع، طول، الگو، محدوده. اگر پارامتری نباید در درخواست باشد، نباید پذیرفته شود. برای مثال، در JSON Schema یا Pydantic (در پایتون) یا Joi (در Node.js)، این کار به‌صورت خودکار قابل انجام است.

Whitelist به‌جای Blacklist

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

Parameterized Query همیشه

در تعامل با دیتابیس، هیچ‌وقت کوئری را با رشته‌سازی (String Concatenation) نمی‌سازم. Parameterized Query یا ORM، جلوی SQL Injection را به‌طور کامل می‌گیرد. تحلیل کامل این حمله در SQL Injection چیست و چگونه جلوگیری کنیم؟ آمده است. برای سیستم‌های NoSQL هم اصل مشابه است؛ اپراتورهایی مثل `$where` و `$regex` هرگز نباید از ورودی کاربر گرفته شوند.

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

امنیت لایه انتقال — TLS و HTTPS

تمام ترافیک API باید از HTTPS عبور کند، حتی در محیط توسعه. بدون TLS، هر کسی در مسیر شبکه می‌تواند توکن‌ها، رمزها و داده‌های حساس را بخواند. اما HTTPS فقط بخشی از داستان است.

نکات عملی که در پروژه‌ها اجرا می‌کنم:

  • نسخه TLS 1.2 حداقل و 1.3 ترجیحاً: TLS 1.0 و 1.1 باید در سرور غیرفعال شوند
  • HSTS (HTTP Strict Transport Security): مرورگر را مجبور می‌کند همیشه از HTTPS استفاده کند
  • عدم ارسال توکن در URL: توکن‌ها باید در هدر باشند، نه در Query String؛ چون URLها در لاگ سرور و مرورگر ذخیره می‌شوند
  • Certificate Pinning در اپلیکیشن موبایل: برای جلوگیری از MITM در دستگاه‌های آلوده

تفاوت HTTPS و HTTP را در HTTPS چیست و چه تفاوتی با HTTP دارد؟ مفصل توضیح داده‌ام. همچنین اگر سرویس شما روی کلاد اجرا می‌شود، مدیریت گواهی‌ها را می‌توان به سرویس‌های مدیریت‌شده ابری سپرد که در امنیت در فضای ابری چگونه تامین می‌شود؟ به آن پرداخته‌ام.

Rate Limiting و کنترل مصرف

بدون Rate Limiting، API شما در برابر حملات Brute Force، Scraping، و حملات مصرف منابع آسیب‌پذیر است. سه استراتژی اصلی که استفاده می‌کنم:

Token Bucket

هر کاربر یک سبد توکن دارد که به‌مرور پر می‌شود و هر درخواست یک توکن مصرف می‌کند. مناسب برای APIهای عمومی که باید امکان انفجار کوتاه‌مدت را بدهند.

Sliding Window

تعداد درخواست‌ها در یک پنجره زمانی مشخص شمارش می‌شود. مثال: حداکثر 100 درخواست در 60 ثانیه. ساده و دقیق، ولی در لبه‌های پنجره ممکن است نوسان ایجاد کند.

Rate Limiting در سطح Endpoint

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

نکته‌ای که در پروژه‌ها فراموش می‌شود: Rate Limiting باید بر اساس شناسه واقعی کاربر باشد، نه فقط IP. در شبکه‌هایی که چند کاربر از یک IP مشترک استفاده می‌کنند (مثل کاربران پشت NAT یا پروکسی)، محدودسازی فقط بر اساس IP باعث آسیب به کاربران واقعی می‌شود.

مدیریت کلیدها و رمزها

بزرگ‌ترین شکارِ مهاجمان در APIها، کلیدهای لو رفته است. در تجربه‌ام، سه اشتباه بیشترین تکرار را دارند:

  • Commit کردن کلیدها در Git: بزرگ‌ترین فاجعه امنیتی که بارها دیده‌ام
  • نگهداری کلید در فایل .env و آپلود آن روی سرور: بدون رمزنگاری در حافظه دیسک
  • استفاده از یک کلید مشترک برای چند سرویس: اگر یک سرویس لو برود، همه لو می‌روند

رویکرد درست: استفاده از Secret Manager (مثل AWS Secrets Manager، HashiCorp Vault، یا حتی سرویس‌های داخلی در Small Scale) که کلیدها را به‌صورت رمزنگاری‌شده نگه می‌دارد و فقط به سرویس‌های مجاز تحویل می‌دهد. برای مدیریت کلیدهای SSH هم اصول مشابهی در امنیت VPS چگونه تامین می‌شود؟ آورده‌ام.

یک نکته مهم در پروژه‌های تیمی: چرخش دوره‌ای کلیدها (Key Rotation). حتی اگر کلید فعلی لو نرفته باشد، چرخش منظم آن، سطح ریسک را کاهش می‌دهد. برای کلیدهای بحرانی، چرخش ساالنه حداقل است.

هدرهای امنیتی HTTP

هدرهای امنیتی HTTP، لایه‌ای نامرئی از دفاع اضافه می‌کنند که در سمت مرورگر اجرا می‌شود. برای APIها، مهم‌ترین هدرها:

  • Content-Security-Policy: برای APIها کمتر حیاتی، ولی برای SPAها ضروری
  • X-Content-Type-Options: nosniff: جلوگیری از حدس نوع محتوا توسط مرورگر
  • Strict-Transport-Security: اجبار استفاده از HTTPS
  • X-Frame-Options: جلوگیری از Clickjacking در APIهای دارای UI
  • Referrer-Policy: کنترل اطلاعات ارسال‌شده در هدر Referer
  • CORS دقیق: لیست Originهای مجاز، نه `*`

راهنمای کامل هر هدر، مقادیر مجاز و سناریوهای استفاده را در هدرهای امنیتی HTTP چه کاربردی دارند؟ آورده‌ام. یک نکته‌ای که در پروژه‌ها زیاد به آن برمی‌خورم: تنظیم CORS با `Access-Control-Allow-Origin: *` به‌همراه `Access-Control-Allow-Credentials: true`. این ترکیب از نظر استاندارد غیرمجاز است، ولی گاهی در تنظیمات نادرست دیده می‌شود.

لاگ‌گیری، پایش و تشخیص نفوذ

بدون لاگ، حمله‌ها را نمی‌بینید؛ بدون پایش، حمله‌ها را نمی‌فهمید. سه دسته اطلاعات که در هر API باید لاگ شود:

  • لاگ درخواست‌ها: URL، متد، IP، User-Agent، زمان، شناسه کاربر (بدون داده حساس)
  • لاگ احراز هویت: تلاش‌های موفق و ناموفق، با شناسه کاربر و منبع
  • لاگ مجوزدهی: رد‌شدن دسترسی، به‌خصوص به منابع دیگران

نکته مهم: هرگز داده‌های حساس مثل رمز، توکن یا شماره کارت را در لاگ ذخیره نکنید. اگر لازم است پاسخ‌ها لاگ شوند، فیلدهای حساس باید ماسک شوند. یکی از رایج‌ترین منشأهای نشت داده، لاگ‌هایی است که به‌اشتباه حاوی توکن‌ها و رمزها هستند.

برای پایش فعال، از دو رویکرد استفاده می‌کنم: بررسی ناهنجاری (Anomaly Detection) بر اساس الگوی ترافیک، و هشدار روی رخدادهای مشخص مثل تعداد بالای خطاهای احراز هویت. ابزارهایی مثل فایروال کاربردی (WAF) می‌توانند لایه اول دفاع باشند؛ مقایسه‌شان را در فایروال ابری در مقابل فایروال سنتی آورده‌ام.

الگوی API Gateway

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

  • احراز هویت متمرکز در لبه
  • Rate Limiting یکنواخت
  • لاگ‌گیری و پایش در یک نقطه
  • مدیریت نسخه‌ها و مسیریابی
  • تبدیل پروتکل و کش پاسخ‌ها

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

نسخه‌بندی و انقضای نسخه‌های قدیمی

نسخه‌بندی (Versioning) در نگاه اول یک موضوع توسعه‌ای به‌نظر می‌رسد، ولی بعد امنیتی مهمی هم دارد. نسخه‌های قدیمی API که هنوز فعال هستند، اغلب باگ‌های امنیتی اصلاح‌نشده دارند و در آمار حملات، سهم بزرگی دارند.

راهبرد من: نسخه‌بندی از ابتدا در URL (مثل `/api/v1/`) و تعیین سیاست انقضا. نسخه‌های قدیمی بعد از یک بازه مشخص (مثلاً 12 یا 18 ماه) باید غیرفعال شوند. راهکارهای فنی نسخه‌بندی را در نسخه‌بندی REST API توضیح داده‌ام. بدون سیاست انقضا، هر نسخه تبدیل به یک بدهی امنیتی می‌شود که تا ابد با شما می‌ماند.

فرهنگ تیم و فرآیند توسعه امن

ابزارها و پیکربندی‌های امنیتی به‌تنهایی کافی نیستند. امنیت API در نهایت، به فرهنگ تیم و فرآیند توسعه بستگی دارد. سه اصل که در تیم‌هایی که با آن‌ها کار کرده‌ام، بیشترین اثر را داشته:

Threat Modeling در ابتدای طراحی

قبل از پیاده‌سازی endpoint جدید، یک جلسه کوتاه برای بررسی «چه کسی ممکن است این endpoint را هدف بگیرد؟» و «چه داده‌ای حساس است؟» برگزار کنید. این جلسه 30 دقیقه‌ای، جلوی بسیاری از بازطراحی‌های گران را می‌گیرد.

Code Review امنیتی

هر Pull Request که به endpoint یا منطق احراز هویت/مجوزدهی دست می‌زند، باید یک بازبین امنیتی داشته باشد. یک چک‌لیست ساده که در تیم‌ها استفاده می‌کنم: بررسی IDOR، بررسی Rate Limiting، بررسی اعتبارسنجی ورودی، بررسی خروجی (Data Exposure).

تست امنیتی منظم

در کنار تست‌های واحد و یکپارچگی، تست امنیتی هم باید بخشی از چرخه CI/CD باشد. ابزارهایی مثل OWASP ZAP در حالت خودکار می‌توانند بخشی از آسیب‌پذیری‌ها را شناسایی کنند. تست نفوذ دوره‌ای هم برای APIهای حیاتی توصیه می‌شود؛ روش‌های عملی در تست api و تست امنیت وب‌سایت چگونه انجام می‌شود؟ آمده است.

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

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

این فهرست، نتیجه سال‌ها بازبینی و تحلیل پروژه‌های واقعی است. هر مورد، دست‌کم یک بار به یک نشت داده یا آسیب‌پذیری جدی منجر شده:

  1. اعتماد به احراز هویت بدون مجوزدهی: چک کردن هویت، بدون چک مالکیت منبع
  2. بازگشت تمام فیلدها در پاسخ: به‌جای بازگشت فیلدهای لازم، تمام شیء کاربر یا محصول ارسال می‌شود
  3. عدم استفاده از Rate Limiting در endpointهای حساس: ورود، فراموشی رمز، ارسال پیامک
  4. استفاده از الگوریتم‌های ضعیف در JWT: `none` یا الگوریتم متقارن ضعیف
  5. ذخیره توکن در localStorage: در معرض XSS است؛ کوکی‌های HttpOnly امن‌ترند. جزئیات در حملات XSS چیست و چگونه جلوگیری کنیم؟
  6. نبود CSRF Protection در APIهای مبتنی بر کوکی: نکات مهم در CSRF چیست و چگونه از آن جلوگیری کنیم؟
  7. CORS گسترده با `*`: باعث می‌شود هر دامنه‌ای بتواند به API شما درخواست بزند
  8. Debug Mode فعال در Production: بازگشت Stack Trace با جزئیات داخلی
  9. نبود جداسازی محیط: استفاده از کلید یکسان در توسعه، تست و پروداکشن
  10. نبود لاگ امنیتی: در صورت نفوذ، هیچ مدرکی برای تحلیل باقی نمی‌ماند

مورد پنجم را در چند پروژه دیده‌ام که فرانت‌اند، توکن JWT را در `localStorage` ذخیره می‌کرد. با یک آسیب‌پذیری XSS ساده در سایت، تمام توکن‌ها به دست مهاجم می‌افتاد. راهکار درست، استفاده از کوکی `HttpOnly` و `Secure` است؛ حتی اگر پیاده‌سازی پیچیده‌تر باشد.

مورد هشتم، نبود جداسازی محیط، در پروژه‌هایی که کلیدهای مشترک در محیط‌های مختلف دارند، یکی از رایج‌ترین منشأهای نشت داده است. مهاجمی که کلید توسعه را پیدا کند، به همان API پروداکشن هم دسترسی خواهد داشت.

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

این بخش، به پرسش‌هایی می‌پردازد که در مشاوره‌ها و بازبینی‌های پروژه، بیشترین تکرار را داشته‌اند.

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

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

آیا JWT از Session-Based Authentication امن‌تر است؟

هیچ‌کدام intrinsically امن‌تر نیستند؛ بستگی به پیاده‌سازی دارد. JWT در معماری‌های stateless و چندسرویسی مزایای مقیاس‌پذیری دارد، ولی اگر مدیریت نشود (Expiration بلند، عدم Revocation)، می‌تواند از Session امنیت کمتری داشته باشد.

برای احراز هویت API موبایل، چه روشی توصیه می‌شود؟

OAuth 2.0 با PKCE (Proof Key for Code Exchange) استاندارد امروز است. برای اپ‌هایی که کاربر ثالث ندارند، JWT با طول عمر کوتاه و Refresh Token امن کافی است. از ذخیره کلید ثابت در اپلیکیشن خودداری کنید؛ اپ موبایل قابل decompile است.

آیا API Gateway تمام امنیت را تامین می‌کند؟

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

چگونه بفهمم API من آسیب‌پذیری دارد؟

سه مسیر عملی: اجرای ابزارهای DAST (Dynamic Application Security Testing) مثل OWASP ZAP روی API خودتان، بازبینی دستی endpointها با چک‌لیست IDOR و Mass Assignment، و سفارش تست نفوذ دوره‌ای. تست خودکار به‌تنهایی کافی نیست؛ تحلیل دستی توسط یک متخصص، آسیب‌پذیری‌های منطقی را پیدا می‌کند که ابزار از آن‌ها غافل است.

آیا امنیت API برای شرکت‌های کوچک هم مهم است؟

بله، ولی مقیاس اهمیت متفاوت است. شرکت کوچک معمولاً هدف حمله اختصاصی نیست، ولی هدف ربات‌های خودکار است که کل اینترنت را اسکن می‌کنند. اصول پایه (HTTPS، Rate Limiting، اعتبارسنجی ورودی، لاگ) با کمترین هزینه قابل پیاده‌سازی است. مطالب بهترین روش‌های امنیت وب کدامند؟ نقطه شروع مناسبی است.

آیا باید از ابزارهای WAF استفاده کنم؟

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

حرف آخر: امنیت، ویژگی پنهانِ هر endpoint

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

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

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