امنیت API؛ OWASP Top ۱۰، OAuth، JWT و چک‌لیست اجرا

یک مهاجم برای سوءاستفاده از API لزوماً به «هک پیچیده» نیاز ندارد. گاهی کافی است شناسه سفارش را در درخواست عوض کند، یک فیلد مدیریتی را به JSON بیفزاید، مرحله تأیید پرداخت را دور بزند یا Endpoint قدیمی و فراموش‌شده‌ای را پیدا کند. اگر Backend مالکیت شیء، سطح مجاز هر فیلد و وضعیت جریان کسب‌وکار را دوباره کنترل نکند، HTTPS، JWT، WAF و حتی Login سالم هم مانع خسارت نمی‌شوند.

پاسخ کوتاه: امنیت API با خرید یک Gateway یا افزودن Rate limit حل نمی‌شود. باید دارایی و سطح حمله را فهرست کنید، در هر درخواست Authentication و Authorization را جداگانه بسنجید، ورودی و خروجی را با Contract محدود کنید، جریان‌های حساس را در برابر اتوماسیون مقاوم سازید، وابستگی‌های بیرونی را نامطمئن فرض کنید و شواهد قابل‌استفاده برای کشف و پاسخ داشته باشید. این راهنما یک برنامه اجرایی برای REST، GraphQL، Webhook و APIهای داخلی ارائه می‌کند.

Snapshot استانداردها: این مقاله در ۶ اوت ۲۰۲۶ بازبینی شده است. مبنای دسته‌بندی ریسک، OWASP API Security Top 10:2023 است؛ نه یک پیش‌بینی بازاری درباره «سال آینده». برای پیاده‌سازی، نسخه دقیق استاندارد، کتابخانه، Identity Provider و Gateway خود را Pin و در Threat model ثبت کنید.

امنیت API دقیقاً از چه چیزی محافظت می‌کند؟

API قرارداد ماشینی میان دو جزء است: مرورگر و Backend، اپ موبایل و سرور، دو Microservice، فروشگاه و درگاه پرداخت یا سیستم شما و یک سرویس ثالث. امنیت آن فقط محرمانگی داده نیست؛ پنج نتیجه باید هم‌زمان حفظ شوند:

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

ابتدا Scope و سطح حمله API را پیدا کنید

تیمی که نمی‌داند چه APIهایی در Production دارد، نمی‌تواند آن‌ها را Patch، مانیتور یا بازنشسته کند. Inventory را از OpenAPI repository، API Gateway، DNS، Cloud account، Mobile/Web bundle، Log و مصاحبه با تیم بسازید؛ نه فقط از مستندات رسمی که ممکن است ناقص باشند.

برای هر API چه چیزی ثبت شود؟

• مالک فنی و مالک کسب‌وکار، Repository و On-call؛
• Host، Environment، Protocol، Version و وضعیت Active/Deprecated؛
• مصرف‌کنندگان مجاز: Browser، Mobile، Partner، Service-to-service یا Public؛
• روش Authentication، Issuer، Audience، Scope و نوع Credential؛
• دسته داده، سطح حساسیت، محل ذخیره و دوره نگه‌داری؛
• جریان‌های حساس مانند Login، OTP، خرید، رزرو، Coupon، Refund و Export؛
• وابستگی‌های ورودی/خروجی، Webhookها و مقصدهای Egress؛
• SLO، سقف بار، هزینه هر درخواست، Log و Runbook رخداد.

Shadow، Zombie و Debug API

Shadow API بدون فرایند رسمی ساخته شده، Zombie API نسخه‌ای است که باید خاموش می‌شد اما هنوز پاسخ می‌دهد، و Debug/Admin endpoint معمولاً برای عملیات ایجاد شده است. هر سه می‌توانند کنترل ضعیف‌تر از مسیر اصلی داشته باشند. تفاوت ترافیک واقعی Gateway با Inventory را ماهانه بررسی کنید و بازنشستگی را با Owner، Deadline، Telemetry و Kill plan انجام دهید.

Threat model سبک اما قابل‌استفاده

برای هر جریان مهم، مسیر «Client → Edge → Gateway → Service → Database/Third party» را بکشید. در هر مرز اعتماد بپرسید: مهاجم چه هویتی دارد؟ چه داده‌ای را کنترل می‌کند؟ چه منابعی مصرف می‌شوند؟ خروجی به کجا می‌رود؟ شکست چه اثر مالی یا عملیاتی دارد؟

خروجی Threat model باید Test case و Owner باشد، نه فقط یک دیاگرام آرشیوی.

ده ریسک OWASP API Security Top ۱۰:۲۰۲۳

Top ۱۰ یک Awareness document است، نه چک‌لیست کامل یا رتبه‌بندی قطعی برای سازمان شما. سه مورد از پنج ریسک اول مستقیماً به Authorization مربوط‌اند؛ بنابراین تمرکز صرف بر Login یا WAF کافی نیست.

Authentication و Authorization را یکی نگیرید

Authentication پاسخ می‌دهد «چه کسی یا چه سرویسی درخواست را فرستاده؟»؛ Authorization پاسخ می‌دهد «این هویت در این لحظه، روی این شیء، فیلد و عمل چه اجازه‌ای دارد؟». Token معتبر فقط هویت یا Client را اثبات می‌کند و مجوز مشاهده هر رکورد را نمی‌دهد.

سه سطح مجوز که باید جداگانه تست شوند

1. Object level: آیا این کاربر به همین سفارش، فایل یا حساب دسترسی دارد؟
2. Property level: کدام فیلدها را می‌تواند بخواند یا بنویسد؟
3. Function level: آیا مجاز است Refund، Export یا حذف انجام دهد؟

کنترل را در Backend و نزدیک داده/عملیات اعمال کنید. مخفی‌کردن دکمه در UI، UUID تصادفی یا بررسی صرف Role در Gateway جای Policy روی Object را نمی‌گیرد.

// شبه‌کد: شناسه ورودی به‌تنهایی معیار دسترسی نیست
order = orders.find(request.params.id)
denyUnless(policy.canRead(user, order))
return orderPresenter.for(user, order) // فقط فیلدهای مجاز

Multi-tenant و رابطه‌های پیچیده

در SaaS، Query باید Tenant boundary را از Context قابل‌اعتماد بگیرد، نه از فیلدی که Client می‌فرستد. عضویت، نقش، مالکیت، Delegation و وضعیت حساب را هم‌زمان لحاظ کنید. تست منفی را با دو کاربر در دو Tenant، دو نقش در یک Tenant و حساب Suspend‌شده اجرا کنید.

OAuth، OIDC، Session و API Key؛ انتخاب بر اساس سناریو

هیچ مکانیزمی برای همه APIها مناسب نیست. OIDC برای هویت کاربر، OAuth برای اعطای دسترسی، Session cookie برای بسیاری از برنامه‌های First-party وب و Credential ماشینی برای Service-to-service کاربرد دارند. API key معمولاً هویت کاربر نهایی و مجوز ریزدانه را ثابت نمی‌کند و نباید تنها محافظ منبع حساس باشد.

OAuth 2.0 Security Best Current Practice (RFC 9700) استفاده از Authorization Code، محدودکردن امتیاز Access token و دفاع در برابر Replay را پوشش می‌دهد و برخی الگوهای قدیمی مانند Implicit و Resource Owner Password Credentials را برای طراحی جدید توصیه نمی‌کند.

JWT نسخه جادویی امنیت نیست

JWT یک قالب Token است، نه جایگزین طراحی Session، Authorization یا Revocation. گاهی Opaque token و Introspection ساده‌تر و کنترل‌پذیرتر است. اگر JWT انتخاب شد، الگوریتم مجاز را در Verifier ثابت کنید و به Header ورودی برای انتخاب Algorithm اعتماد نکنید.

• امضا، نوع Token و الگوریتم دقیق را اعتبارسنجی کنید؛ none پذیرفته نشود.
• iss، aud، exp و در صورت نیاز nbf را بررسی کنید.
• Access token کوتاه‌عمر، Scope حداقلی و Key rotation با kid کنترل‌شده داشته باشید.
• داده حساس را صرفاً به دلیل Signed بودن داخل Payload نگذارید؛ Payload لزوماً رمز‌شده نیست.
• برای Logout، Compromise و تغییر نقش، Strategy ابطال یا Session state تعریف کنید.
• Tokenهای با کاربرد متفاوت را با Audience، Type و Validation rule جدا کنید.

جزئیات حملات Confusion، Validation و جداسازی کاربرد در JWT Best Current Practices (RFC 8725) آمده است. توصیه ثابت «همیشه RS256» دقیق نیست؛ انتخاب Algorithm تابع معماری اعتماد و پشتیبانی امن Library است.

BOLA، BOPLA و BFLA را چگونه تست کنیم؟

برای هر Endpoint ماتریس Subject × Object × Property × Action بسازید. تست Happy path کافی نیست؛ ارزش اصلی در Negative test است.

برای معماری و ریسک‌های ویژه Query، مقاله مقایسه GraphQL و REST مکمل این بخش است.

جریان‌های حساس کسب‌وکار و سوءاستفاده خودکار

API ممکن است هیچ Bug کلاسیکی نداشته باشد اما عملکرد مجاز آن در مقیاس، کسب‌وکار را آسیب بزند: ساخت حساب جعلی، رزرو موجودی، Scraping قیمت، مصرف Coupon، ارسال نظر، OTP bombing، خرید محدود یا Refund پیاپی. این API6 است و فقط با Rate limit ثابت IP حل نمی‌شود.

کنترل متناسب با جریان

• محدودیت چندبعدی بر Account، Device، IP/ASN، مقصد، Tenant و Action؛
• سقف Velocity و Value، نه فقط تعداد Request؛
• State machine و Idempotency برای عملیات مالی؛
• Step-up authentication برای ریسک بالاتر؛
• Queue، Reservation expiry و Fairness rule برای موجودی کمیاب؛
• Risk scoring با مسیر Appeal برای False positive؛
• هشدار بر نسبت موفقیت، الگوی توزیع و اثر مالی.

برای Login و بازیابی حساب، الگوی دفاع چندلایه در راهنمای Brute Force و Credential Stuffing آمده است.

محدودکردن منابع و هزینه هر درخواست

Rate limiting فقط تعداد درخواست نیست. API می‌تواند با یک Query بسیار سنگین، Upload بزرگ، Pagination نامحدود، Regex پرهزینه یا فراخوانی SMS/AI/پرداخت منابع را مصرف کند.

• حداکثر Body، Header، Upload، Page size، Query depth/complexity و زمان اجرا؛
• Timeout و Cancellation از Edge تا Database و Dependency؛
• Concurrency و Queue bound برای کارهای سنگین؛
• Quota و Budget برای سرویس‌های هزینه‌زا؛
• Backpressure، Circuit breaker و Bulkhead؛
• پاسخ استاندارد ۴۲۹ و Retry-After بدون ایجاد Retry storm؛
• Load test با سناریوی بدترین Query و وابستگی کند.

SSRF؛ URL ورودی را مثل کد خطرناک ببینید

Endpointهایی مانند Import URL، Webhook tester، PDF generator، Image fetcher و Proxy ممکن است سرور را وادار کنند به مقصدی که مهاجم انتخاب کرده وصل شود. Parse رشته یا Block کردن چند IP کافی نیست؛ Redirect، IPv6، DNS rebinding، Encoding و Cloud metadata مسیرهای دورزدن‌اند.

کنترل دفاعی SSRF

• در صورت امکان کاربر مقصد دلخواه تعیین نکند؛
• Scheme، Host و Port با Parser معتبر و Allowlist بررسی شوند؛
• IP نهایی پس از Resolve و در هر Redirect کنترل شود؛
• Loopback، Link-local، Private network و Metadata endpoint مسدود شوند؛
• Egress شبکه فقط مقصدهای لازم را مجاز کند؛
• Redirect خودکار خاموش یا مرحله‌به‌مرحله اعتبارسنجی شود؛
• Timeout، Response-size limit و Content-type check اعمال شود؛
• Credential داخلی به درخواست مقصد ناشناس پیوست نشود.

API ثالث هم ورودی نامطمئن است

نام برند فروشنده جای Validation را نمی‌گیرد. OWASP در API10 بر Unsafe Consumption تأکید می‌کند: پاسخ سرویس ثالث می‌تواند خراب، بسیار بزرگ، کند، Redirectشده یا آلوده باشد.

• Contract و Schema پاسخ، نوع، طول و دامنه مقدار را Validate کنید؛
• Timeout، Retry محدود با Jitter، Circuit breaker و سقف Response داشته باشید؛
• Redirect را کورکورانه دنبال نکنید؛
• دسترسی شبکه و Credential هر Integration را جدا و حداقلی کنید؛
• Provenance، SLA، Change notification و Exit plan فروشنده را بسنجید؛
• Failure mode را مشخص کنید: Fail closed، Queue یا تجربه محدود؟
• داده Third-party پیش از Database، Template، Shell یا Downstream دوباره ایمن شود.

امنیت Webhook و Callback

Webhook یک API ورودی از طرف سیستم دیگر است. IP allowlist به‌تنهایی شکننده است و HTTPS اصالت پیام را ثابت نمی‌کند.

1. امضا را روی Raw body و با Secret/Key مستقل Verify کنید.
2. Timestamp و Window کوتاه را بررسی و Nonce/Event ID را برای Replay ثبت کنید.
3. پردازش را Idempotent کنید؛ تحویل تکراری رفتار عادی بسیاری از Providerهاست.
4. دریافت، Verify و Queue را سریع انجام دهید؛ Business processing جدا باشد.
5. Secret rotation با دوره هم‌پوشانی کنترل‌شده و Audit داشته باشید.
6. وضعیت مالی را فقط از داده Browser Return نپذیرید؛ Server-side Verify و Reconciliation لازم است.

برای چرخه پرداخت ایرانی، راهنمای اتصال امن درگاه پرداخت State machine، Verify و Reconciliation را با جزئیات توضیح می‌دهد.

Contract امن: ورودی کم، خروجی کم

OpenAPI، JSON Schema یا GraphQL Schema زمانی کنترل امنیتی است که در Code review، Test و Runtime enforce شود. «هر فیلدی که Client فرستاد را به ORM بده» همان Mass assignment است.

• فیلد، نوع، طول، Format، Enum، Range و Nested depth را Allowlist کنید؛
• Unknown property را طبق Policy رد یا صریحاً Ignore کنید؛
• DTO ورودی را از Domain model و DTO خروجی جدا کنید؛
• Response بر اساس مخاطب Serialize شود و PII اضافی بازنگردد؛
• HTTP method و Content-Type مجاز محدود باشند؛
• Error عمومی، Correlation ID و Log داخلی جدا داشته باشید؛ Stack trace و Query افشا نشود؛
• Pagination محدود و Sorting/Filtering روی Fieldهای مجاز باشد.

OWASP REST Security Cheat Sheet بر HTTPS، Access control در هر Endpoint، محدودیت Method و اعتبارسنجی Claimهای Token تأکید می‌کند.

CORS، CSRF و تفاوت Clientها

CORS مکانیزم کنترل دسترسی سرور برای هر Client نیست؛ Policy مرورگر است. درخواست Mobile، Server یا ابزار خط فرمان می‌تواند Header دلخواه بفرستد. Access-Control-Allow-Origin: * با Credential نیز الگوی امن عمومی نیست.

• Originهای مرورگری لازم را دقیق Allowlist و Vary: Origin را درست تنظیم کنید؛
• برای Cookie-based authentication، CSRF token/SameSite و Origin check را متناسب با جریان اعمال کنید؛
• Token را در URL نگذارید؛ URL در History، Referer و Log نشت می‌کند؛
• Browser storage و XSS را در مدل تهدید Token لحاظ کنید؛
• برای پاسخ حساس، Cache policy را آگاهانه تعیین کنید.

Gateway و WAF چه می‌کنند و چه نمی‌کنند؟

Gateway جای مناسبی برای TLS termination، Authentication اولیه، Routing، اندازه درخواست، Rate limit، Quota و Telemetry مشترک است. WAF می‌تواند الگوهای شناخته‌شده و برخی Abuseها را کم کند. اما هیچ‌کدام معمولاً نمی‌دانند آیا کاربر A مالک سفارش ۴۵۶ است یا Refund در وضعیت فعلی مجاز است.

تنظیم Detection و Rollout کم‌ریسک در راهنمای فایروال و WAF سایت آمده است.

Secret، API key و Credential ماشینی

• Secret داخل Repository، Image، Mobile app، Frontend bundle یا Log قرار نگیرد؛
• Credential برای هر Environment و Consumer جدا باشد؛
• Scope، Audience، IP/Network یا Sender constraint در صورت امکان محدود شود؛
• Secret manager، Rotation، Expiry و Revocation آزمایش‌شده داشته باشید؛
• Detection برای استفاده هم‌زمان از مکان‌های نامعمول و Spike تعریف کنید؛
• در رخداد، ابتدا دامنه مصرف را بسنجید و Rotation را طوری انجام دهید که Evidence از بین نرود.

API key عمومی داخل اپ موبایل یا JavaScript «راز» نیست. می‌تواند برای Identification و Quota مفید باشد، اما منبع حساس به کنترل دیگری نیاز دارد.

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

Shift-left مفید است، اما امنیت نباید فقط به ابتدای چرخه منتقل شود. Design، Build، Deploy و Runtime هرکدام Gate و Feedback لازم دارند.

ابزار اسکن معمولاً منطق مالکیت و جریان مالی را کامل کشف نمی‌کند. تست Integration باید کاربر، Tenant، Role، Field و State متفاوت بسازد. Exception امنیتی نیز Owner، دلیل، کنترل جبرانی و تاریخ انقضا می‌خواهد.

Logging و Observability بدون نشت داده

برای تشخیص حمله به Context نیاز دارید، نه ذخیره بی‌ضابطه Body و Token. Access token، Password، OTP، Cookie، کلید API و داده پرداخت باید Redact شوند. دسترسی به Log محدود، انتقال رمز‌شده و Retention متناسب با نیاز باشد.

فیلدهای مفید رویداد امنیتی

• Timestamp استاندارد، Request/Trace ID، Service و Version؛
• Actor/Client/Tenant pseudonymous ID و Authentication method؛
• Route template، Method، Status، Latency و Response size؛
• Policy decision، Reason code و Object type بدون PII غیرضروری؛
• Rate-limit dimension، Dependency و نتیجه Verify؛
• Deployment/config version برای Correlation تغییر.

برای طراحی Metric، Log و Trace و کنترل Cardinality، راهنمای Observability را ببینید.

Runbook پاسخ به رخداد API

1. Triage: اثر، Endpoint، داده، Tenant، Actor و شروع زمانی را مشخص کنید.
2. Preserve: Log، Trace، Config، Deploy و نمونه Request را با دسترسی کنترل‌شده حفظ کنید.
3. Contain: Token/Key را محدود یا با برنامه Rotate کنید؛ Route، Function یا Flow را موقتاً ببندید؛ Rate/WAF rule هدفمند اعمال کنید.
4. Eradicate: Root cause در AuthZ، State، Schema، Inventory یا Dependency را اصلاح کنید.
5. Recover: تست منفی، Rollout مرحله‌ای، Telemetry و Rollback criteria داشته باشید.
6. Assess: رکوردهای خوانده/تغییریافته، تراکنش مالی و نیاز ارتباطی/حقوقی را با متخصص مربوط بسنجید.
7. Learn: Test regression، Owner و Deadline اقدامات Postmortem را ثبت کنید.

قطع کلی API شاید خسارت بیشتری از حمله ایجاد کند. Containment باید کمترین Scope لازم، Break-glass و مسیر بازگشت داشته باشد.

ملاحظات ویژه تیم و بازار ایران

OTP و هزینه سرویس بیرونی

ارسال پیامک، استعلام هویت، نقشه، AI یا درگاه می‌تواند به‌ازای هر درخواست هزینه بسازد. علاوه بر Rate، سقف هزینه روزانه، Alert ریالی، Circuit breaker و حالت Degraded تعریف کنید. OTP bombing را روی مقصد، Account، Device و IP بسنجید.

تحریم، دسترسی و تغییر Provider

وابستگی خارجی ممکن است به‌دلیل محدودیت حساب، پرداخت، IP یا منطقه ناگهان تغییر کند. Secret مشترک، Failover کور و Proxy ناشناخته ریسک را بیشتر می‌کند. Data flow، محل پردازش، خروج اضطراری، Provider دوم و تست بازیابی را مستند کنید.

شبکه و False positive

کاربران زیادی ممکن است پشت NAT، VPN یا IP متغیر باشند؛ Block ثابت IP می‌تواند مشتری سالم را حذف کند. Rate limit را چندبعدی و Risk-based کنید، مسیر Challenge/Recovery داشته باشید و KPI خطای مثبت کاذب را جدا بسنجید.

تومان، ریال و منطق مالی

مبلغ، تخفیف، هزینه ارسال و وضعیت پرداخت از Client پذیرفته نشود. واحد پول در Contract صریح، محاسبه Server-side، عملیات مالی Idempotent و Reconciliation مستقل باشد.

Scorecard بلوغ امنیت API

وزن‌ها را بر اساس ریسک خود تغییر دهید. امتیاز بالا نباید Gate حیاتی را پنهان کند: نبود Authorization روی تراکنش مالی با چند ابزار اسکن جبران نمی‌شود.

برنامه ۹۰روزه پیاده‌سازی

روز ۱ تا ۱۵: دیدپذیری و خطر فوری

• Inventory اولیه، Owner و دسته‌بندی داده؛
• انتخاب پنج جریان حیاتی و رسم Threat model؛
• تست BOLA/BOPLA/BFLA روی Endpointهای حساس؛
• حذف Secretهای آشکار و بستن Admin/Debug عمومی؛
• تعریف Log حداقلی با Redaction.

روز ۱۶ تا ۴۵: کنترل‌های اصلی

• Policy مرکزی در Code و Testهای منفی؛
• Schema ورودی/خروجی و State machine؛
• Token validation، Scope و Rotation؛
• Rate/Resource budget، Webhook verification و Egress policy؛
• Contract lint و Security test در CI.

روز ۴۶ تا ۹۰: عملیات و مقیاس

• کشف Shadow/Zombie API از Traffic؛
• Dashboard و Alert برای Authorization، Abuse و Cost؛
• Drill نشت Token، BOLA و Provider outage؛
• Deprecation و Retirement gate؛
• Scorecard، Exception expiry و مرور فصلی Threat model.

اشتباه‌های رایج

• «JWT داریم، پس امنیم»: Token معتبر می‌تواند درخواست غیرمجاز بسازد.
• «UUID قابل حدس نیست»: Authorization نباید به پنهان‌بودن ID وابسته باشد.
• «WAF همه‌چیز را می‌گیرد»: WAF مالکیت سفارش یا State مالی را نمی‌فهمد.
• «API داخلی قابل‌اعتماد است»: حساب یا Service داخلی هم ممکن است آلوده شود.
• «Rate limit روی IP کافی است»: NAT، Botnet و Abuse ارزش/هزینه را نادیده می‌گیرد.
• «داده سرویس معتبر امن است»: Third-party response نیز باید Validate و محدود شود.
• «اسکن سبز یعنی Production امن است»: ابزار خودکار معمولاً Business logic را کامل پوشش نمی‌دهد.

سوالات متداول امنیت API

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

خیر. HTTPS محرمانگی و یکپارچگی ارتباط در مسیر را فراهم می‌کند، اما BOLA، دسترسی فیلد، سوءاستفاده منطق تجاری، Credential دزدیده‌شده یا SSRF را برطرف نمی‌کند.

تفاوت BOLA و BFLA چیست؟

BOLA درباره دسترسی غیرمجاز به یک Object مشخص مانند سفارش کاربر دیگر است؛ BFLA درباره اجرای Function یا Action غیرمجاز مانند حذف کاربر یا Refund مدیریتی. هر دو به کنترل Backend و تست منفی نیاز دارند.

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

به‌صورت مطلق خیر. امنیت به معماری Client، محل نگه‌داری، Validation، عمر، Revocation و مدل تهدید بستگی دارد. Session امن یا BFF برای بعضی وب‌اپ‌ها ساده‌تر است؛ JWT برای برخی معماری‌های توزیع‌شده مفید است اما هزینه و ریسک خاص خود را دارد.

API Gateway جای Authorization در سرویس را می‌گیرد؟

Gateway می‌تواند Authentication اولیه، Route، Quota و محدودیت مشترک را اعمال کند؛ اما تصمیم مالکیت Object، فیلد و گذار وضعیت معمولاً به Context کسب‌وکار داخل سرویس نیاز دارد.

از کدام API برای شروع ممیزی کنیم؟

از جریان‌هایی شروع کنید که پول، داده حساس، نقش مدیریتی، Export، OTP، Webhook یا دسترسی Third-party دارند. پنج جریان با ترکیب «اثر بالا × دسترسی بیرونی × تغییر زیاد» انتخاب و برایشان Inventory، Threat model و Negative test بسازید.

جمع‌بندی

امنیت API یک محصول نیست؛ زنجیره‌ای از تصمیم‌های قابل‌اثبات است. Inventory به شما می‌گوید چه دارید، Threat model می‌گوید چه چیزی ممکن است بشکند، Authorization و Contract جلوی دسترسی اشتباه را می‌گیرند، محدودیت منابع و Egress دامنه سوءاستفاده را کم می‌کنند و Telemetry/Runbook زمان کشف و مهار را پایین می‌آورند. اگر می‌خواهید این مسیر برای APIهای واقعی، درگاه‌ها و تیم شما به Backlog اولویت‌دار تبدیل شود، درخواست مشاوره فنی و امنیت را ثبت کنید.