بازگشت به کتابخانهکتابخانه10.2Threat Modeling و امنیت API
طراحی سیستم نرم‌افزاریSYSTEM DESIGNاز صفر تا تسلط
v1.0.0
01مبانی و تصویر بزرگ
02Scalability و ظرفیت
03لایه داده
04Cache، Queue و جریان
05معماری نرم‌افزار
06قابلیت اطمینان و عملیات
07متد طراحی
08Case Study های واقعی
09سیستم‌های توزیع‌شده عمیق
10مهندسی تولید: داده، امنیت و کارایی
11تمرین پیشرفته و کیس‌استادی‌های مکمل
12زیر کاپوت دیتابیس و معماری داده
13وب بلادرنگ و پروتکل‌های مدرن
14سیستم‌های توزیع‌شده پیشرفته
15SaaS ،SRE ،امنیت و شبکه پیشرفته
16طراحی سیستم در عصر AI
17Case Study های تکمیلی
LESSON 10.2فصل ۱۰مهندسی تولید: داده، امنیت و کارایی

Threat Modeling و امنیت API

  • ~۱۵ دقیقه
  • ۲ پرسش
  • متن را انتخاب کن تا هایلایت شود

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

فرایند تهدیدشناسی

  • دارایی‌ها را بنویس: پول، PII، credential، availability و audit log. سپس data-flow diagram و trust boundary بکش.
  • برای هر جریان STRIDE را مرور کن: Spoofing، Tampering، Repudiation، Information disclosure، Denial of service، Elevation of privilege.
  • کنترل و owner و روش آزمون هر تهدید را ثبت کن؛ threat model سند زندهٔ هر تغییر معماری است.
AuthN / AuthZ
هویت با مجوز فرق دارد؛ هر سرویس باید authorization را روی resource و tenant enforce کند، نه فقط gateway.
OAuth/OIDC
OIDC هویت می‌دهد؛ OAuth delegation و scope می‌دهد. redirect URI، PKCE و audience را دقیق validate کن.
mTLS / workload identity
هویت سرویس‌به‌سرویس با certificate یا identity کوتاه‌عمر؛ secret ثابت در env کافی نیست.
Secret rotation
کلیدها version دارند، دو کلید موقتاً هم‌زیست‌اند و rotation قابل audit و rollback است.
WAF/Bot/DDoS
rate limit، CDN/WAF، quota و waiting room لایه‌های متفاوتند؛ هیچ‌کدام جای authorization نیست.

خطاهای رایج API: BOLA/IDOR (دسترسی به resource دیگر با تغییر ID)، mass assignment، injection، SSRF و leak در log. شناسه غیرقابل حدس کمک می‌کند اما authorization server-side درمان اصلی است. PII را در log/token/URL نگذار و retention/delete policy را از طراحی data model جدا نکن.

به زبان ساده

امنیت از فهرست‌کردن شروع می‌شود: چه چیزی ارزشمند است، چه کسی حمله می‌کند و هر API باید چه چیزی را چک کند — بعد سراغ ابزار می‌رویم.

مثال واقعی

کاربر در آدرس /orders/1042 عدد را به 1043 تغییر می‌دهد؛ اگر API فقط «وجود» سفارش را چک کند، سفارش شخص دیگر را می‌بیند. باید owner_id با کاربر لاگین‌شده یکی باشد.

دانش‌سنجی

آزمون درس

۲ Q
01
تغییر order_id در URL و دیدن سفارش کاربر دیگر کدام ضعف است؟
02
بهترین محل enforce کردن مجوز برای منبع حساس؟