چک‌لیست امنیتی API

July 21, 2026 · View on GitHub

English | 繁中版 | 简中版 | العربية | Azərbaycan | Български | বাংলা | Català | Čeština | Deutsch | Ελληνικά | Español | Français | हिंदी | Indonesia | Italiano | 日本語 | 한국어 | ພາສາລາວ | Македонски | മലയാളം | Монгол | Nederlands | Polski | Português (Brasil) | Русский | ไทย | Türkçe | Українська | Tiếng Việt

چک‌لیست امنیتی API

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

احراز هویت

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

دسترسی

  •       رکوئست‌ها را محدود کنید (Throttling) تا از حملات DDos یا بروت‌فورس جلوگیری شود.
  •       در سمت سرور از HTTPS استفاده کنید تا از حملات مرد میانی جلوگیری شود.
  •       از هدر HSTS استفاده کنید تا از حمله‌ی SSL Strip جلوگیری شود.
  •       لیست های دایرکتوری را خاموش کنید.
  •       برای APIهای خصوصی، فقط از IPها/میزبانهای لیست سفید اجازه دسترسی داشته باشید.

مجوز

OAuth

  •       همیشه redirect_uri را در سمت سرور اعتبارسنجی کنید تا تنها به URLهای مجاز اجازه داده شود.
  •       همیشه تلاش کنید تا code را به جای token تبادل کنید (اجازه response_type=token را ندهید).
  •       از پارامتر state با یک هش تصادفی استفاده کنید تا از CSRF روی پروسه‌ی احراز هویت OAuth جلوگیری کنید.
  •       مقدار scope پیش‌فرض را تعریف کنید و پارامترهای scope را برای هر اپلیکیشن اعتبارسنجی کنید.

ورودی

  •       از متد HTTP مناسب با توجه به نوع عملیات استفاده کنید: GET برای خواندن، POST برای ایجاد کردن، PUT/PATCH برای جایگزین یا بروزرسانی و DELETE برای حذف یک رکورد، و در صورتی‌که متد درخواستی برای منبع درخواست‌شده مناسب نباشد با 405 Method Not Allowed پاسخ بدهید.
  •       مقدار content-type را در هدر Accept رکوئست (مذاکره محتوا یا Content Negotiation) اعتبارسنجی کنید تا فقط به فرمت‌های مورد پشتیبانی اجازه داده شود (مثلا application/xml، application/json و ...). و در صورت عدم تطابق با یک پاسخ 406 Not Acceptable پاسخ دهید.
  •       مقدار content-type در داده‌ی پست‌شده را اعتبارسنجی کنید (مثلا application/x-www-form-urlencoded، multipart/form-data، application/json و ...).
  •       ورودی کاربر را اعتبارسنجی کنید تا از آسیب‌پذیری‌های معمول جلوگیری شود (مثلا XSS، SQL-Injection و Remote Code Execution).
  •       هیچ داده‌ی حساسی مثل (داده‌های اعتبارسنجی، پسوورد‌ها، توکن‌های امنیتی یا کلید‌های API) را داخل URL قرار ندهید و از هدر Authorization استاندارد استفاده کنید.
  •       فقط از رمزگذاری سمت سرور استفاده کنید.
  •       از یک سرویس API Gateway استفاده کنید تا کش‌کردن و سیاست‌های Rate Limit (مثلا Quota، Spike Arrest یا Concurrent Rate Limit) فعال شوند و منابع APIها را به صورت داینامیک دپلوی کنید.

پردازش

  •       چک کنید که تمامی endpointها توسط احراز هویت محافظت شوند تا از پروسه‌ی احراز هویت ناقص جلوگیری شود.
  •       از استفاده از ID ریسورس خود کاربر اجتناب کنید. به جای user/654321/orders از /me/orders استفاده کنید.
  •       از IDهای auto-increment استفاده نکنید. به جای آن از UUID استفاده کنید.
  •       اگر فایل‌های XML را parse می‌کنید مطمئن شوید تا entity parsing غیرفعال باشد تا از XXE (XML External entity attack) جلوگیری شود.
  •       اگر فایل‌های XML، YAML یا هر زبان دیگری را با استفاده از anchor ها و ref ها parse می‌کنید، مطمئن شوید تا entity expansion غیرفعال باشد تا از Billion Laughs/XML bomb توسط exponential entity expansion attack جلوگیری شود.
  •       از یک CDN برای آپلودهای فایل استفاده کنید.
  •       اگر با مقادیر بسیار حجیمی از داده سر و کار دارید، از Workerها و Queueها استفاده کنید تا حد الامکان پردازش در بک‌گراند انجام شود و سریع پاسخ را برگردانید تا از HTTP Blocking جلوگیری شود.
  •       خاموش کردن حالت DEBUG را فراموش نکنید.
  •       در صورت وجود از پشته های غیر قابل اجرا استفاده کنید.

خروجی

  •       هدر X-Content-Type-Options: nosniff را ارسال کنید.
  •       هدر X-Frame-Options: deny را ارسال کنید.
  •       هدر 'Content-Security-Policy: default-src 'none را ارسال کنید.
  •       هدرهایی که به نوعی اثرانگشت برجای می‌گذارند را حذف کنید، مثلا X-Powered-By، Server و ‍X-AspNet-Version.
  •       مقدار content-type را برای پاسخ اجباری کنید. اگر application/json برمیگردانید، پس content-type پاسخ، application/json است.
  •       از ارائه اطلاعات و متن خطا های با جزعیات داخلی به کاربر بپرهیزید و از پیام های خطای عمومی و ساده استفاده کنید. تنها اطلاعات با جزعیات را در سمت سرور ثبت کنید.
  •       اطلاعات حساس مثل داده‌های اعتبارسنجی، رمز های عبور و توکن‌های امنیتی را برنگردانید.
  •       با توجه به عملیات انجام‌شده، status code مناسب را برگردانِد. مثلا 200 OK، 400 Bad Request، 401 Unauthorized و 405 Method Not Allowed.

ادغام و استقرار مداوم

  •       طراحی و پیاده سازی خودتان را با پوشش تست‌های unit/integration بازرسی کنید.
  •       از یک پروسه‌ی مرور کد استفاده کنید و خود-تاییدی را نادیده بگیرید.
  •       مطمئن شوید تا تمامی اجزای سرویس‌هایتان، شامل کتابخانه‌های استفاده‌شده و دیگر وابستگی‌ها، قبل از انتشار در حالت production، به طور ایستا توسط نرم‌افزارهای آنتی‌ویروس اسکن شده‌اند.
  •       به صورت پیوسته روی کدتان تست‌های امنیتی (آنالیز ایستا و پویا)، اجرا کنید.
  •       وابستگی‌هایتان (نرم افزار و سیستم عامل، هردو) را برای آسیب‌پذیری‌های شناخته شده، چک کنید.
  •       برای دپلوی‌هایتان، یک راه‌حل با قابلیت عقبگرد (rollback) طراحی کنید.

نظارت

  •       از لاگین های متمرکز برای همه سرویس ها و مؤلفه ها استفاده کنید.
  •       از agent ها برای مانیتور همه ترافیک, خطاها, درخواست‌ها و پاسخ‌ها استفاده کنید.
  •       از alert ها برای اس ام اس, Slack, ایمیل, Telegram, Kibana, Cloudwatch و غیره استفاده کنید.
  •       اطمینان حاصل کنید که هیچ گونه داده حساسی مانند کارت های اعتباری، رمزهای عبور، پین ها و غیره را ثبت نمی کنید.
  •       از یک سیستم IDS و/یا IPS برای مانیتور درخواست ها API و نمونه های خود استفاده کنید.

نگاهی بیاندازید به:

  • yosriady/api-development-tools - یک مجموعه از منابع مفید برای ساختن APIهای RESTful با HTTP و JSON -
  • شما به JWT نیازی ندارید؛ تنها کافیست از یک کلید تصادفی ساخته شده استفاده کنید. اگر نیاز به استفاده از رمزنگاری نامتقارن یا جلوگیری از دستکاری دارید:
  • جایگزین های JWT

دستورالعمل های امنیت API (پیشرفته)

محودیت میزان و جلوگیری از سوءاستفاده

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

امنیت مختص به GraphQL

  •       را در محیط های عملیاتی غیرفعال کنید introspection
  •       محدودیت عمق پرس و جو را برای جلوگیری از حملات مبتنی برای پرس و جو های تو‌در‌تو در نظر داشته باشید.
  •       هزینه های مربوط به پرس‌وجو را برای جلوگیری از اتمام منابع تحلیل کنید.
  •       تاحد امکان پرس‌و‌جو های مجاز را به صورت لیست سفید در محیط های عملیاتی قرار بدهید.

مدیریت اعتبارات و رمزها

  •       چرخش و تعویض کلید های API را در بازهای زمانی مرتبط در نظر داشته باشید.
  •       از مولفه سخت‌افزاری امنیتی (HSM) برای عملیات های امضا استفاده کنید.
  •       در چرخه های استقرار و ادغام مداوم رمز ها و اعتبارات را بررسی کنید.
  •       هرگز رمز ها را در مخزن های کنترل نسخه قرار ندهید و از متغیرهای محیطی یا ابزارهای مدیریت رمز استفاده کنید.

معماری بدون اعتماد

  •       پیاده سازی TLS دوطرفه (mTLS) را برای ارتباطات سرویس به سرویس درنظر بگیرید.
  •       همه درخواست هارا اعتبارسنجی کنید حتی درخواست های داخلی.
  •       از توکن ها با طول عمر کوتاه با قابلیت تازه‌سازی خودکار استفاده کنید.
  •       برای عملیات های حساس امضا درخواست ها را مدنظر قرار دهید.

مشارکت

برای همکاری و کمک می‌توانید به راحتی این مخزن را fork کنید، تغییرات مورد نظرت را اعمال کنید و یک pull request ثب کنید. اگر سوالی داشتید به آدرس team@shieldfy.io ایمیل بزنید.