Insecure Design چیست؟ چرا طراحی ناامن می‌تواند کل امنیت سایت را به خطر بیندازد؟

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

برای مثال، اگر یک سیستم بازیابی حساب از ابتدا طوری طراحی شده باشد که تنها با اطلاعات قابل حدس بتوان هویت کاربر را تأیید کرد، اصلاح Syntax کد یا نصب WAF مشکل اصلی را برطرف نمی‌کند. راهکار واقعی، تغییر Workflow بازیابی حساب و تعریف یک طراحی امن‌تر است.

OWASP در نسخه Top 10 سال ۲۰۲۵، Insecure Design را با شناسه A06 معرفی کرده است. این دسته روی ضعف‌های معماری و طراحی، Business Logic، Trust Boundary، مدیریت جریان‌های غیرعادی و نبود کنترل‌های امنیتی موردنیاز تمرکز دارد. OWASP تأکید می‌کند یک طراحی امن ممکن است به‌دلیل خطای برنامه‌نویسی به آسیب‌پذیری تبدیل شود، اما یک طراحی اساساً ناامن را نمی‌توان فقط با Implementation بی‌نقص امن کرد.

Insecure Design دقیقاً چیست؟

برای درک Insecure Design ابتدا باید تفاوت میان «طراحی نرم‌افزار» و «پیاده‌سازی نرم‌افزار» را بشناسیم.

قبل از اینکه توسعه‌دهنده اولین خط Code را بنویسد، تصمیم‌های زیادی گرفته می‌شوند:

کاربر چگونه ثبت‌نام می‌کند؟

چگونه هویت او تأیید می‌شود؟

چه Roleهایی در سیستم وجود دارند؟

چه اطلاعاتی حساس هستند؟

چه کسی اجازه مشاهده یا تغییر اطلاعات را دارد؟

اگر کاربر درخواست غیرعادی ارسال کند چه اتفاقی می‌افتد؟

چه محدودیتی برای عملیات حساس وجود دارد؟

اگر یک سرویس از دسترس خارج شود، برنامه چگونه رفتار می‌کند؟

آیا یک Tenant می‌تواند به اطلاعات Tenant دیگر نزدیک شود؟

فرآیند بازیابی Password چگونه انجام می‌شود؟

سیستم در برابر Bot، Abuse و Automation چه واکنشی دارد؟

این تصمیم‌ها بخش مهمی از Design هستند.

اگر پاسخ این پرسش‌ها از ابتدا اشتباه باشد، سیستم ممکن است در سطح بنیادی آسیب‌پذیر طراحی شود.

OWASP، Insecure Design را دسته‌ای گسترده از ضعف‌هایی می‌داند که از «کنترل‌های طراحی ناقص یا ناکارآمد» ناشی می‌شوند. در OWASP Top 10 2025 این دسته ۳۹ CWE را پوشش می‌دهد و در داده‌های مورد بررسی OWASP بیش از ۷۲۹ هزار رخداد و ۷۶۴۷ CVE مرتبط با CWEهای این دسته ثبت شده است.

جایگاه Insecure Design در OWASP Top 10 2025

Insecure Design برای نخستین بار به‌صورت یک دسته مستقل در OWASP Top 10 2021 معرفی شد و در آن نسخه رتبه چهارم را داشت.

در نسخه ۲۰۲۵ این دسته به A06 منتقل شده است.

ترتیب بخشی از OWASP Top 10 2025 به شکل زیر است:

OWASP توضیح می‌دهد که Insecure Design در نسخه ۲۰۲۵ دو رتبه پایین‌تر آمده و یکی از دلایل مطرح‌شده، پیشرفت نسبی صنعت در زمینه Threat Modeling و افزایش توجه به Secure Design است. این تغییر رتبه به معنی بی‌اهمیت شدن طراحی ناامن نیست؛ بلکه همچنان یکی از ده ریسک اصلی امنیت برنامه‌های وب محسوب می‌شود.

تفاوت Insecure Design و Insecure Implementation چیست؟

این مهم‌ترین مفهومی است که هنگام بررسی طراحی ناامن باید درک شود.

Design تعیین می‌کند سیستم «چه کاری باید انجام دهد و چه کنترل‌هایی باید داشته باشد».

Implementation تعیین می‌کند آن طراحی «چگونه در Code پیاده‌سازی شود».

برای مثال تصور کنید یک فروشگاه اینترنتی تصمیم گرفته است هر حساب کاربری بتواند روزانه حداکثر پنج Coupon تخفیف ایجاد کند.

این محدودیت بخشی از Design است.

اگر طراحی این محدودیت را تعریف کرده باشد اما توسعه‌دهنده هنگام برنامه‌نویسی بررسی تعداد Couponها را فراموش کند، با یک Implementation Defect روبه‌رو هستیم.

اما اگر اساساً هیچ محدودیتی برای ایجاد Coupon در Specification وجود نداشته باشد و کاربران بتوانند به‌صورت نامحدود Coupon ایجاد کنند، مشکل ریشه‌ای‌تر است.

در این حالت برنامه دقیقاً همان چیزی را انجام می‌دهد که طراحی شده است، اما Design ناامن است.

OWASP به‌صراحت تأکید می‌کند که یک Secure Design ممکن است به دلیل Implementation Defect آسیب‌پذیر شود، اما یک Insecure Design حتی با پیاده‌سازی کامل و بدون Bug نیز نمی‌تواند امنیت مورد انتظار را ایجاد کند.

چرا طراحی ناامن می‌تواند کل امنیت سایت را به خطر بیندازد؟

یک Bug معمولی ممکن است تنها یک Endpoint یا قابلیت خاص را تحت تأثیر قرار دهد.

اما Design Decision معمولاً در چندین بخش سیستم تکرار می‌شود.

اگر مدل Authentication اشتباه باشد، بخش بزرگی از حساب‌های کاربران تحت تأثیر قرار می‌گیرند.

اگر Tenant Isolation از ابتدا درست طراحی نشده باشد، تعداد زیادی سرویس و Database Query ممکن است به آن وابسته باشند.

اگر Trust Boundary اشتباه تعریف شده باشد، چندین Component ممکن است به داده‌ای اعتماد کنند که نباید Trusted باشد.

اگر Business Logic محدودیت لازم را نداشته باشد، ممکن است تمام Endpointهای مرتبط همان رفتار خطرناک را داشته باشند.

به همین دلیل اصلاح Insecure Design معمولاً پرهزینه‌تر از اصلاح یک Bug ساده است.

گاهی باید:

Database Schema تغییر کند.

API Contract بازطراحی شود.

Authentication Flow تغییر کند.

Permission Model بازنویسی شود.

Frontend و Backend همزمان اصلاح شوند.

Migration داده انجام شود.

Test Caseهای جدید ایجاد شوند.

Policy سازمان تغییر کند.

به همین دلیل Secure by Design می‌گوید امنیت باید در مرحله طراحی وارد محصول شود، نه اینکه پس از پایان توسعه به‌عنوان یک Feature جانبی روی آن نصب شود.

چرا نصب WAF مشکل Insecure Design را حل نمی‌کند؟

Web Application Firewall یا WAF ابزار مفیدی برای دفاع لایه‌ای است.

WAF می‌تواند برخی Requestهای مخرب، Patternهای Injection یا رفتارهای مشکوک را شناسایی و مسدود کند.

اما WAF نمی‌داند Business Logic واقعی برنامه چیست.

فرض کنید سیستم اجازه می‌دهد هر کاربر بدون محدودیت ۵۰۰ بار در دقیقه یک عملیات مالی قانونی انجام دهد.

Request از نظر Syntax کاملاً معتبر است.

Authentication نیز موفق است.

هیچ SQL Injection یا XSS وجود ندارد.

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

WAF الزاماً نمی‌تواند تشخیص دهد این رفتار خلاف منطق کسب‌وکار است.

در اینجا باید Design مشخص کند:

محدودیت چیست؟

چه تعداد عملیات طبیعی است؟

چه زمانی رفتار مشکوک است؟

چه کسی باید تأیید اضافی ارائه کند؟

چه عملیات‌هایی باید Idempotent باشند؟

چه زمانی نیاز به Step-up Authentication داریم؟

به همین دلیل Application Security نباید فقط به Firewall و Scanner وابسته باشد.

Business Logic چگونه به Insecure Design مرتبط می‌شود؟

Business Logic یا منطق کسب‌وکار مجموعه قوانینی است که مشخص می‌کند برنامه چگونه باید رفتار کند.

برای مثال در یک فروشگاه:

قیمت کالا چگونه تعیین می‌شود؟

Discount چگونه محاسبه می‌شود؟

موجودی چه زمانی کم می‌شود؟

Refund تحت چه شرایطی مجاز است؟

کاربر چند Coupon می‌تواند استفاده کند؟

چه کسی می‌تواند سفارش را لغو کند؟

در یک سامانه مالی:

حداقل و حداکثر انتقال چقدر است؟

چه زمانی تأیید مجدد هویت لازم است؟

آیا عملیات تکراری باید پذیرفته شود؟

چه اتفاقی در Transaction Failure می‌افتد؟

اگر این قوانین ناقص طراحی شوند، مهاجم ممکن است بدون استفاده از Exploit فنی پیچیده از رفتار قانونی سیستم سوءاستفاده کند.

OWASP در توضیح A06:2025 مشخصاً به نقص‌های Business Logic و تعریف نشدن State Transitionهای ناخواسته یا غیرمنتظره اشاره می‌کند.

Business Logic Abuse چیست؟

Business Logic Abuse زمانی اتفاق می‌افتد که فرد از Featureهای واقعی برنامه به شکلی استفاده کند که توسعه‌دهندگان انتظار نداشته‌اند.

برای مثال یک سیستم ممکن است بگوید:

«کاربر می‌تواند رزرو ایجاد کند.»

اما مشخص نکرده باشد:

هر کاربر چند رزرو همزمان می‌تواند داشته باشد؟

رزرو چه مدت معتبر است؟

آیا کاربر بدون پرداخت می‌تواند ظرفیت زیادی را رزرو کند؟

آیا تعداد درخواست‌ها محدود است؟

آیا Bot می‌تواند این فرآیند را خودکار کند؟

در این حالت Function اصلی درست کار می‌کند، اما Abuse Case در Design لحاظ نشده است.

OWASP یکی از مثال‌های A06 را سیستمی مطرح می‌کند که محدودیت مناسب برای رزرو گروهی ندارد و می‌توان با سوءاستفاده از Business Logic ظرفیت زیادی را بدون الزام متناسب درگیر کرد.

Security Requirement چیست؟

بسیاری از پروژه‌ها Requirementهای Functional خوبی دارند اما Security Requirement مشخصی ندارند.

Functional Requirement ممکن است بگوید:

«کاربر باید بتواند Password خود را بازیابی کند.»

اما Security Requirement باید مشخص کند:

Token بازیابی باید یک‌بارمصرف باشد.

Token باید زمان انقضا داشته باشد.

پس از تغییر Password، Sessionهای حساس قدیمی باید طبق Policy مدیریت شوند.

تلاش‌های بیش از حد باید محدود شوند.

فرآیند بازیابی نباید فقط به اطلاعات عمومی کاربر متکی باشد.

رویداد بازیابی باید در صورت نیاز Log شود.

در عملیات حساس شاید Notification ارسال شود.

بدون Security Requirement توسعه‌دهنده مجبور است تصمیم‌های امنیتی را در زمان Coding حدس بزند.

این دقیقاً یکی از مسیرهایی است که می‌تواند به Insecure Design منجر شود.

Threat Modeling چیست؟

Threat Modeling یا مدل‌سازی تهدید یک فرآیند ساختاریافته برای نگاه کردن به سیستم از دید امنیتی است.

OWASP Threat Modeling را فرآیندی تکرارپذیر معرفی می‌کند که ابتدا سیستم را از منظر امنیت مدل می‌کند، سپس Threatهای مرتبط را شناسایی و برای آن‌ها Response مناسب تعیین می‌کند. OWASP همچنین توصیه می‌کند Threat Modeling در مراحل اولیه SDLC، به‌ویژه هنگام Design انجام شود و یک فعالیت یک‌باره نباشد.

در یک Threat Modeling ساده می‌توان چهار سؤال اصلی مطرح کرد:

چه چیزی در حال ساختن است؟

چه چیزی ممکن است اشتباه شود؟

برای آن چه کاری انجام می‌دهیم؟

آیا اقدامات ما کافی هستند؟

Threat Modeling چه چیزهایی را آشکار می‌کند؟

Threat Modeling می‌تواند مواردی را آشکار کند که Scanner معمولی قادر به مشاهده آن‌ها نیست.

برای مثال:

Trust Boundary نامناسب

Roleهای بیش از حد قدرتمند

Business Logic قابل سوءاستفاده

مسیر بازیابی ناامن

وابستگی خطرناک به سرویس خارجی

Data Flow غیرضروری

Single Point of Failure

نبود Rate Limiting

نبود Tenant Isolation

Workflow قابل دور زدن

عدم اعتبارسنجی State Transition

همین موضوع Threat Modeling را به یکی از مهم‌ترین روش‌های مقابله با Insecure Design تبدیل می‌کند.

Threat Modeling باید چه زمانی انجام شود؟

Threat Modeling نباید فقط در پایان پروژه و درست قبل از Penetration Test انجام شود.

بهترین زمان برای آن زمانی است که هنوز تغییر Design ارزان است.

برای مثال:

زمان طراحی محصول

قبل از ساخت Authentication

هنگام اضافه کردن Payment

هنگام طراحی API جدید

هنگام ایجاد Role جدید

هنگام اضافه کردن File Upload

هنگام مهاجرت به Cloud

هنگام اضافه کردن Integration خارجی

هنگام تغییر Data Flow

هنگام ساخت قابلیت مالی

پس از Incident مهم

همچنین پس از تغییرهای اساسی Architecture باید Threat Model بازبینی شود.

Trust Boundary چیست؟

Trust Boundary مرزی است که هنگام عبور Data از آن، سطح اعتماد تغییر می‌کند.

برای مثال:

Browser کاربر و Backend

Internet و Internal Network

Frontend و API

Application و Database

سرویس داخلی و Third-party API

Tenant A و Tenant B

Admin Panel و Public Application

هیچ Data نباید صرفاً به این دلیل که «از داخل سیستم» آمده، Trusted فرض شود.

اگر Backend به داده‌ای که Frontend ارسال کرده اعتماد کامل داشته باشد، ممکن است طراحی خطرناک شود.

یک مثال ساده

فرض کنید Frontend هنگام خرید محصول مقدار زیر را ارسال کند:

قیمت کالا: ۲ میلیون تومان

Backend نیز همان مبلغ ارسال‌شده را بدون محاسبه مجدد بپذیرد.

حتی اگر Frontend قیمت را در UI غیرقابل ویرایش نمایش دهد، Data همچنان تحت کنترل Client است.

Design امن باید Critical State مانند Price، Permission، Discount و Ownership را در یک Trust Boundary قابل اعتماد تعیین یا اعتبارسنجی کند.

این اصل با مفهوم «هرگز به Client برای تصمیم‌های امنیتی اعتماد نکن» مرتبط است.

State Transition چیست؟

بسیاری از برنامه‌ها دارای State هستند.

برای مثال یک سفارش ممکن است مراحل زیر را داشته باشد:

Created

Awaiting Payment

Paid

Processing

Shipped

Delivered

Cancelled

Refunded

در Design باید مشخص باشد هر State به چه Stateهایی اجازه انتقال دارد.

برای مثال آیا سفارش Delivered می‌تواند مستقیماً به Awaiting Payment بازگردد؟

آیا سفارش Cancelled می‌تواند Shipped شود؟

آیا User می‌تواند State را تعیین کند یا Server؟

اگر Transitionهای مجاز تعریف نشده باشند، ممکن است سیستم وضعیت‌های منطقی غیرممکن یا خطرناک ایجاد کند.

OWASP در A06:2025 مشخصاً تعریف نکردن تغییرات State ناخواسته یا غیرمنتظره را نمونه‌ای از Risk مرتبط با Insecure Design می‌داند.

Abuse Case و Misuse Case چیست؟

Use Case توضیح می‌دهد کاربر قانونی چگونه از سیستم استفاده می‌کند.

برای مثال:

«کاربر وارد حساب می‌شود و سفارش خود را مشاهده می‌کند.»

Abuse Case از زاویه مخالف به قابلیت نگاه می‌کند:

«اگر فرد تلاش کند تعداد زیادی درخواست ایجاد کند چه می‌شود؟»

«اگر کاربر Workflow را خارج از ترتیب طی کند چه اتفاقی می‌افتد؟»

«اگر درخواست قانونی را هزار بار تکرار کند چه؟»

«اگر مقدار مرزی یا غیرعادی وارد شود چه؟»

«اگر دو Request همزمان ارسال شوند چه؟»

استفاده از Abuse Case باعث می‌شود تیم توسعه فقط Happy Path را طراحی نکند.

Happy Path چیست و چرا خطرناک است؟

Happy Path مسیری است که همه چیز طبق انتظار پیش می‌رود.

مثلاً:

کاربر ثبت‌نام می‌کند.

ایمیل تأیید می‌شود.

Login می‌کند.

محصول انتخاب می‌کند.

پرداخت موفق انجام می‌شود.

اما امنیت عمدتاً در مسیرهایی آزمایش می‌شود که همه چیز طبق انتظار پیش نمی‌رود.

چه می‌شود اگر پرداخت Fail شود؟

چه می‌شود اگر Callback دوبار ارسال شود؟

اگر User Browser را ببندد چه؟

اگر Request تکرار شود چه؟

اگر Session وسط فرآیند منقضی شود چه؟

اگر دو Request همزمان باشند چه؟

اگر سرویس خارجی Timeout دهد چه؟

Secure Design باید Failure Path و Edge Case را همان‌قدر جدی بگیرد که Happy Path را.

Secure by Design چیست؟

Secure by Design یعنی Security یکی از Requirementهای اصلی محصول باشد و از مراحل ابتدایی طراحی در Architecture و Workflowها لحاظ شود.

OWASP Secure Product Design توصیه می‌کند طراحی محصول با Secure Defaults، کاهش Attack Surface و Fail Secure آغاز شود و تصمیم‌های امنیتی به‌صورت آگاهانه و صریح در چرخه توسعه گرفته شوند.

CISA نیز در Secure by Design تأکید می‌کند که تولیدکننده نرم‌افزار باید مسئولیت بیشتری نسبت به نتیجه امنیتی محصول برعهده بگیرد و بار اصلی امن‌سازی محصول را به کاربر نهایی منتقل نکند.

Secure by Default

Secure by Default یعنی حالت پیش‌فرض نرم‌افزار باید تا حد منطقی امن باشد.

مثلاً:

Debug پیش‌فرض خاموش باشد.

Featureهای حساس بدون Authentication فعال نباشند.

Access Control حداقل سطح دسترسی را اعمال کند.

API خصوصی به‌صورت تصادفی Public نشود.

Security Feature مهم نیازمند فعال‌سازی پیچیده توسط کاربر نباشد.

اصل مهم این است که «آسان‌ترین مسیر استفاده» نباید «ناامن‌ترین مسیر» باشد.

اصل Deny by Default

Deny by Default یعنی اگر سیستم مطمئن نیست عملیات مجاز است، درخواست باید رد شود.

این اصل خصوصاً برای Authorization اهمیت دارد.

Design ضعیف گاهی این‌گونه است:

«اگر کاربر Admin نبود، شاید بتواند این Operation را انجام دهد مگر اینکه جایی ممنوع شده باشد.»

Design بهتر:

«هیچ کاربری مجاز نیست مگر Permission صریح داشته باشد.»

این تغییر کوچک در فلسفه طراحی می‌تواند از تعداد زیادی Access Control Failure جلوگیری کند.

Fail Secure چیست؟

Fail Secure یا Fail Closed یعنی اگر یک Control امنیتی با خطا مواجه شد، سیستم به حالت امن برگردد.

برای مثال اگر سرویس Authorization پاسخ ندهد:

Design ناامن:

«چون نتوانستیم Permission را بررسی کنیم، Request را Allow کنیم تا سرویس Down نشود.»

Design امن:

«تا زمانی که Permission تأیید نشده، عملیات حساس انجام نشود.»

Fail Secure یکی از اصول مهم Secure Product Design است.

البته رفتار دقیق باید با Availability Requirement و Threat Model سازگار باشد؛ اما Failure نباید ناخواسته کنترل امنیتی را حذف کند.

Least Privilege چیست؟

Least Privilege یعنی هر User، Process یا Service فقط حداقل Permission لازم برای انجام وظیفه خود را داشته باشد.

اگر Web Application فقط نیاز به Read و Update روی دو Table دارد، استفاده از Database Account با دسترسی کامل به تمام Schemaها طراحی مناسبی نیست.

اگر Support Agent فقط باید Ticketها را ببیند، نباید Permission تغییر Role کاربران را داشته باشد.

Least Privilege باعث می‌شود در صورت Compromise شدن یک Component، Blast Radius محدودتر شود.

Separation of Duties چیست؟

Separation of Duties یعنی عملیات حساس به‌گونه‌ای طراحی شوند که یک شخص یا Component به تنهایی کنترل کامل نداشته باشد.

مثلاً در یک سامانه مالی ممکن است:

فرد اول درخواست برداشت را ایجاد کند.

فرد دوم درخواست را تأیید کند.

یا برای عملیات بسیار حساس Step-up Authentication اعمال شود.

هدف این اصل کاهش امکان Abuse، Error یا Compromise یک حساب است.

Defense in Depth چیست؟

Defense in Depth یعنی امنیت به یک Control وابسته نباشد.

مثلاً برای حفاظت از Admin Panel می‌توان ترکیبی از موارد زیر داشت:

Authentication

MFA

Authorization

Network Restriction

Session Security

Rate Limiting

Logging

Alerting

Secure Configuration

حتی اگر یکی از این Controlها Fail شود، سایر لایه‌ها همچنان ریسک را کاهش می‌دهند.

OWASP Secure Product Design، Defense in Depth را یکی از اصول مهم طراحی امن معرفی می‌کند.

Attack Surface چیست؟

Attack Surface تمام نقاطی است که یک مهاجم بالقوه می‌تواند با سیستم تعامل داشته باشد.

این نقاط ممکن است شامل:

صفحات عمومی

Login

API

Webhook

Admin Panel

File Upload

GraphQL

WebSocket

Mobile API

Third-party Integration

SSH

Database Port

Storage Bucket

باشند.

Secure Design تلاش می‌کند Attack Surface غیرضروری را کاهش دهد.

هر Feature جدید معمولاً سطح حمله را افزایش می‌دهد.

این بدان معنا نیست که Feature جدید ایجاد نشود؛ بلکه باید Security Cost آن نیز هنگام تصمیم‌گیری بررسی شود.

چرا Rate Limiting یک تصمیم طراحی است؟

Rate Limiting را بسیاری فقط یک Configuration می‌دانند، اما محل و منطق اعمال آن اغلب بخشی از Design است.

فرض کنید Endpoint بازیابی Password وجود دارد.

باید مشخص شود:

چند Request در دقیقه مجاز است؟

محدودیت براساس IP است یا Account؟

آیا Distributed Attack در نظر گرفته شده؟

پس از چند تلاش Step-up Control اعمال می‌شود؟

آیا Response باعث User Enumeration می‌شود؟

Rate Limit برای Login، Password Reset، OTP، Search، Coupon، Checkout، API و عملیات پرهزینه می‌تواند اهمیت زیادی داشته باشد.

اگر هیچ‌کدام از این مسائل در Design تعریف نشده باشد، اضافه کردن یک Limit تصادفی در Production ممکن است هم ناکافی باشد و هم کاربران واقعی را دچار مشکل کند.

Secure Design در احراز هویت

Authentication یکی از مهم‌ترین بخش‌هایی است که باید قبل از Coding طراحی امنیتی داشته باشد.

سؤال‌هایی مانند موارد زیر باید پاسخ داده شوند:

آیا MFA وجود دارد؟

برای چه Roleهایی اجباری است؟

Session چه مدت معتبر است؟

Refresh Token چگونه مدیریت می‌شود؟

پس از تغییر Password چه اتفاقی برای Sessionها می‌افتد؟

Account Recovery چگونه انجام می‌شود؟

Brute Force چگونه محدود می‌شود؟

چه رفتارهایی نیازمند Re-authentication هستند؟

Device Trust چگونه مدیریت می‌شود؟

بدون این تصمیم‌ها تیم برنامه‌نویسی ممکن است هر بخش Authentication را به روش متفاوتی پیاده‌سازی کند.

طراحی ناامن در Password Recovery

Password Recovery نمونه بسیار خوبی از Insecure Design است.

فرض کنید سایت برای بازیابی حساب سؤال‌هایی مانند این بپرسد:

نام اولین مدرسه شما چیست؟

نام خانوادگی مادر چیست؟

شهر تولد شما کجاست؟

حتی اگر Code این Feature کاملاً بدون Bug باشد، Design ممکن است ضعیف باشد؛ زیرا پاسخ بسیاری از این سؤال‌ها می‌تواند قابل کشف، حدس یا مهندسی اجتماعی باشد.

OWASP در مثال‌های رسمی A06:2025 به Workflow بازیابی Credential مبتنی بر Question and Answer به‌عنوان طراحی نامناسب اشاره می‌کند.

راهکار، Patch کردن Regex نیست.

باید Workflow بازیابی حساب بازطراحی شود.

Insecure Design در File Upload

File Upload فقط مسئله بررسی Extension نیست.

قبل از Implementation باید Design مشخص کند:

چه کسی اجازه Upload دارد؟

چه نوع فایل‌هایی واقعاً لازم هستند؟

حداکثر Size چیست؟

فایل کجا ذخیره می‌شود؟

آیا Web Server می‌تواند آن را Execute کند؟

نام فایل چگونه تعیین می‌شود؟

آیا فایل Public است؟

آیا Download نیازمند Authorization است؟

آیا Content-Type بررسی می‌شود؟

آیا فایل پردازش مجدد می‌شود؟

Retention آن چقدر است؟

اگر معماری فایل آپلودشده را مستقیماً داخل Web Root و با Permission خطرناک ذخیره کند، ممکن است مشکل عمیق‌تر از یک Validation ناقص باشد.

Insecure Design در API

API Security به‌شدت به طراحی وابسته است.

Design باید از ابتدا مشخص کند:

Resource Ownership چگونه کنترل می‌شود؟

Authorization Object-Level چگونه اعمال می‌شود؟

Versioning چگونه انجام می‌شود؟

Rate Limit چیست؟

چه Dataهایی Return می‌شوند؟

Filtering و Pagination چه محدودیتی دارند؟

Idempotency چگونه مدیریت می‌شود؟

Webhook چگونه Authenticity را بررسی می‌کند؟

Error Response چه اطلاعاتی منتشر می‌کند؟

Token Scope چیست؟

اگر API ابتدا بدون مدل Permission مشخص طراحی شود، بعداً افزودن Authorization به ده‌ها Endpoint می‌تواند پیچیده و پرخطا باشد.

Insecure Design در سایت‌های چندکاربره و SaaS

Multi-tenancy یکی از حساس‌ترین معماری‌ها از نظر Secure Design است.

در یک SaaS چندمستاجره باید مشخص باشد:

Tenant ID از کجا تعیین می‌شود؟

آیا Client می‌تواند آن را تغییر دهد؟

Database Shared است یا جدا؟

Cache چگونه Tenant-aware است؟

Search Index چگونه جدا می‌شود؟

File Storage چگونه Isolation دارد؟

Background Job چه Tenant Contextی دارد؟

Logها اطلاعات Tenant دیگر را نمایش می‌دهند؟

Admin Support چگونه دسترسی می‌گیرد؟

OWASP در توصیه‌های A06 بر Robust Tenant Segregation در تمام Tierهای برنامه تأکید می‌کند.

Tenant Isolation نباید صرفاً به یک WHERE ساده که توسعه‌دهنده باید در هر Query به خاطر بسپارد وابسته باشد.

معماری باید احتمال خطای انسانی را کاهش دهد.

Insecure Design در فروشگاه اینترنتی

فروشگاه اینترنتی دارای Business Logic پیچیده‌ای است.

موارد زیر باید قبل از Development طراحی شوند:

Price Calculation

Coupon

Inventory

Payment

Refund

Cart

Shipping

Order Status

Guest Checkout

Gift Card

Loyalty Point

اگر Client بتواند Price نهایی را تعیین کند یا Backend هیچ Consistency Check نداشته باشد، سیستم ممکن است در معرض Abuse قرار گیرد.

موجودی کالا

تصور کنید فقط یک کالا باقی مانده است و دو کاربر همزمان Checkout می‌کنند.

اگر Concurrency در Design لحاظ نشده باشد، هر دو ممکن است تصور کنند کالا را خریداری کرده‌اند.

این موضوع لزوماً «حمله» نیست؛ اما همان ضعف می‌تواند در Abuse Scenario نیز مورد استفاده قرار گیرد.

Secure Design باید Race Conditionهای حساس را در نظر بگیرد.

Insecure Design در WooCommerce و WordPress

وردپرس و WooCommerce بخش زیادی از Architecture عمومی را فراهم می‌کنند، اما سایت نهایی ممکن است همچنان Design ناامن داشته باشد.

این مسئله بیشتر در موارد زیر دیده می‌شود:

Plugin اختصاصی

REST API سفارشی

Ajax Endpoint

Membership System

Wallet

Point System

Coupon Logic

File Upload

Custom Checkout

Role سفارشی

Integration مالی

اتصال CRM

مثال Role در وردپرس

فرض کنید سایت یک Role سفارشی به نام Seller ایجاد می‌کند.

اگر هنگام Design دقیقاً مشخص نشده باشد Seller چه Capabilityهایی باید داشته باشد، ممکن است توسعه‌دهنده برای ساده‌سازی Permission بسیار گسترده‌ای اختصاص دهد.

مشکل اصلی در این حالت فقط یک Check گمشده نیست؛ Permission Model از ابتدا مبهم بوده است.

WooCommerce و Business Logic

فرض کنید Plugin اختصاصی تخفیف بر اساس تعداد محصول ایجاد می‌کند.

قبل از Coding باید مشخص شود:

آیا Couponها Stack می‌شوند؟

حداکثر Discount چیست؟

Refund با تخفیف چگونه محاسبه می‌شود؟

Order Edit چه اثری دارد؟

Guest User مجاز است؟

آیا Discount روی Shipping هم اعمال می‌شود؟

اگر این Ruleها تعریف نشوند، Business Logic می‌تواند رفتارهای غیرمنتظره ایجاد کند.

Insecure Design و Broken Access Control چه تفاوتی دارند؟

این دو دسته OWASP ارتباط زیادی با هم دارند.

Broken Access Control یعنی کنترل دسترسی به‌درستی اعمال نشده است.

Insecure Design ممکن است دلیل عمیق‌تری برای ایجاد چنین ضعفی باشد.

برای مثال:

اگر Role Model وجود دارد ولی یک Endpoint Authorization را فراموش کرده، بیشتر با Broken Access Control مواجه هستیم.

اگر Role Model اساساً مشخص نمی‌کند چه کسی به چه چیزی دسترسی دارد، مشکل Design نیز وجود دارد.

بنابراین یک Vulnerability می‌تواند ابعاد مختلفی داشته باشد.

Insecure Design و Security Misconfiguration

Security Misconfiguration معمولاً مربوط به تنظیم اشتباه Componentها یا محیط است.

برای مثال:

Debug فعال

Directory Listing

Cloud Storage عمومی

Service غیرضروری فعال

اما اگر Architecture طوری طراحی شده باشد که همه Storageها باید Public باشند چون سیستم هیچ روش دیگری برای توزیع File ندارد، مسئله می‌تواند به Design نیز برگردد.

تفاوت اصلی در Root Cause است.

Insecure Design و Injection

Injection معمولاً ناشی از نحوه پردازش Data در Implementation است.

Parameterized Query می‌تواند SQL Injection را کاهش دهد.

اما اگر سیستم اجازه دهد کاربر به‌طور قانونی Query بسیار پرهزینه یا غیرمحدود ایجاد کند، ممکن است مشکل Business Logic یا Design نیز وجود داشته باشد.

به همین دلیل OWASP Top 10 دسته‌ها را کاملاً جدا از یکدیگر نمی‌داند؛ بعضی Riskها می‌توانند همپوشانی داشته باشند.

Secure Development Lifecycle یا SSDLC چیست؟

Secure Software Development Lifecycle یعنی Security در تمام مراحل چرخه توسعه حضور داشته باشد.

نه فقط در Penetration Test پایانی.

مراحل ممکن است شامل:

Planning

Requirements

Design

Development

Testing

Deployment

Operations

Maintenance

باشند.

NIST در Secure Software Development Framework یا SSDF مجموعه‌ای از Practiceهای سطح‌بالا را ارائه می‌کند که می‌توانند داخل SDLCهای مختلف ادغام شوند. هدف این Framework کاهش Vulnerabilityهای نرم‌افزار، کاهش Impact مشکلات کشف‌نشده و رسیدگی به Root Cause آسیب‌پذیری‌ها است.

چرا Shift Left به‌تنهایی کافی نیست؟

Shift Left معمولاً به این معنی است که Security Testing را زودتر در Development انجام دهیم.

این رویکرد مفید است.

اما اگر «سمت چپ» فقط Coding باشد، هنوز ممکن است دیر باشد.

OWASP در نسخه ۲۰۲۵ اشاره می‌کند که باید از Shift Left صرفاً در Coding عبور کرد و Security را به Requirement Writing و Application Design نیز برد.

اگر Architecture در مرحله Design اشتباه باشد، SAST در مرحله Coding ممکن است هیچ چیزی گزارش نکند.

کد می‌تواند از نظر Syntax و Security APIها صحیح باشد، اما Workflow همچنان ناامن باشد.

نقش Architect و AppSec در طراحی امن

Secure Design فقط وظیفه Security Team نیست.

افراد مختلف باید مشارکت داشته باشند:

Product Owner

Developer

Software Architect

AppSec Engineer

DevOps

SRE

Database Engineer

Business Owner

Privacy Team

QA

تیم Security باید در مراحل ابتدایی پروژه در دسترس باشد، اما نمی‌تواند تمام تصمیم‌های طراحی را به‌تنهایی بگیرد.

Developer و Product Team باید Business Context را توضیح دهند و AppSec باید Threat و Controlهای لازم را وارد Discussion کند.

Paved Road چیست؟

OWASP در Secure Development توصیه می‌کند سازمان Library یا مجموعه‌ای از Secure Design Patternها و Paved-road Componentها ایجاد کند.

Paved Road یعنی مسیر امن برای توسعه‌دهنده ساده‌تر شود.

مثلاً به‌جای اینکه هر Team سیستم Authentication خودش را بسازد، سازمان یک Component استاندارد ارائه کند که:

MFA دارد.

Session امن دارد.

Logging دارد.

Password Reset استاندارد دارد.

Rate Limiting دارد.

Security Test دارد.

در نتیجه Developer مجبور نیست در هر پروژه امنیت را از صفر اختراع کند.

Secure Design Pattern چیست؟

Design Pattern امن یک راهکار شناخته‌شده برای مسئله پرتکرار معماری است.

برای مثال:

Centralized Authorization

Server-side Session Management

Secure Password Recovery

Queue-based Processing

Tenant-aware Data Access

Tokenization

Input Validation Layer

Paved-road Authentication

هدف Pattern کاهش تصمیم‌گیری‌های تکراری و استفاده از تجربه قبلی است.

طراحی برای Plausibility Check

OWASP توصیه می‌کند در هر Tier برنامه Plausibility Check وجود داشته باشد.

یعنی فقط بررسی نکنیم Data از نظر Format صحیح است؛ بررسی کنیم از نظر Business Logic هم معقول است.

مثلاً:

تعداد محصول منفی نباشد.

Discount از ۱۰۰ درصد بیشتر نباشد.

Transfer از Limit حساب عبور نکند.

تاریخ پایان قبل از تاریخ شروع نباشد.

کاربر نتواند Role خودش را به Admin تغییر دهد.

Amount پرداخت با Order واقعی تطابق داشته باشد.

این Checks باید در Server و Tier قابل اعتماد انجام شوند.

Unit Test و Integration Test برای Design Security

Test امنیتی فقط Scanner نیست.

Business Ruleهای مهم باید Test Case داشته باشند.

مثلاً:

User A نمی‌تواند Resource متعلق به User B را ببیند.

Coupon بیشتر از سقف تعیین‌شده اعمال نمی‌شود.

Refund بیش از مبلغ پرداخت‌شده انجام نمی‌شود.

Request تکراری Transaction دوم ایجاد نمی‌کند.

Expired Token پذیرفته نمی‌شود.

Cancelled Order دوباره Shipped نمی‌شود.

Tenant A هیچ Data متعلق به Tenant B دریافت نمی‌کند.

OWASP توصیه می‌کند Unit و Integration Test برای Flowهای حیاتی براساس Threat Model ایجاد شوند.

Negative Testing چیست؟

Test معمولی می‌پرسد:

«آیا قابلیت درست کار می‌کند؟»

Negative Test می‌پرسد:

«اگر کاربر کاری را که نباید انجام دهد امتحان کند چه؟»

مثلاً:

اگر مرحله دوم Workflow قبل از مرحله اول فراخوانی شود چه؟

اگر Request دوبار ارسال شود چه؟

اگر Role غیرمجاز Endpoint را فراخوانی کند چه؟

اگر مقدار صفر، منفی یا بسیار بزرگ باشد چه؟

اگر سرویس خارجی پاسخ ندهد چه؟

اگر Database Timeout کند چه؟

Negative Testing برای شناسایی ضعف‌های Design بسیار ارزشمند است.

چرا SAST و DAST به‌تنهایی Insecure Design را پیدا نمی‌کنند؟

SAST Source Code را بررسی می‌کند.

DAST برنامه در حال اجرا را از بیرون تست می‌کند.

هر دو بسیار مفید هستند.

اما فرض کنید برنامه به کاربران اجازه دهد در هر ساعت هزار Gift Card بسازند و Business Owner فراموش کرده باشد Limit تعریف کند.

Scanner از کجا باید بداند Limit صحیح پنج عدد بوده است؟

این اطلاعات فقط در Business Context وجود دارند.

ابزار ممکن است:

SQL Injection

XSS

Hard-coded Secret

Misconfiguration

را پیدا کند.

اما بسیاری از Design Flawها نیازمند:

Threat Modeling

Architecture Review

Business Logic Review

Manual Testing

Domain Knowledge

هستند.

معماری Secure by Design برای سایت چگونه شکل می‌گیرد؟

یک Architecture امن معمولاً چند ویژگی دارد.

اول، Trust Boundaryها مشخص هستند.

دوم، Authentication و Authorization مرکزی هستند.

سوم، Sensitive Data به حداقل می‌رسد.

چهارم، Componentها حداقل Permission لازم را دارند.

پنجم، Failure State مشخص است.

ششم، Logging و Alerting بخشی از Architecture هستند.

هفتم، Critical Flowها Negative Test دارند.

هشتم، Dependencyهای خارجی به شکل Blind Trusted در نظر گرفته نمی‌شوند.

نهم، Tenant Isolation یا Data Separation در لایه مناسب انجام می‌شود.

دهم، Design قابل تغییر و بازبینی است.

Secure Design یک Diagram ثابت نیست؛ یک فرآیند مداوم تصمیم‌گیری است.

روش مرحله‌به‌مرحله جلوگیری از Insecure Design

مرحله اول: دارایی‌های حساس را مشخص کنید

ابتدا باید بدانید چه چیزهایی ارزش محافظت دارند.

مانند:

حساب کاربران

اطلاعات مالی

اطلاعات شخصی

API Key

File خصوصی

Transaction

Admin Capability

Business Data

مرحله دوم: Business Risk را مشخص کنید

برای هر قابلیت بپرسید:

اگر سوءاستفاده شود چه اتفاقی می‌افتد؟

آیا خسارت مالی دارد؟

آیا اطلاعات کاربران افشا می‌شود؟

آیا Availability تحت تأثیر قرار می‌گیرد؟

آیا Reputation آسیب می‌بیند؟

OWASP نبود Business Risk Profile را یکی از عوامل Insecure Design می‌داند.

مرحله سوم: Security Requirement بنویسید

Security Requirement را مانند Functional Requirement مستند کنید.

مثلاً:

تمام Operationهای مالی نیازمند Authentication هستند.

تغییر شماره تماس نیازمند Re-authentication است.

هر Tenant تنها Resourceهای خودش را می‌بیند.

Token بازیابی حساب حداکثر مدت مشخصی اعتبار دارد.

مرحله چهارم: Data Flow را ترسیم کنید

مشخص کنید Data:

از کجا می‌آید؟

به کجا می‌رود؟

کجا ذخیره می‌شود؟

چه Serviceهایی آن را پردازش می‌کنند؟

در کدام نقطه Trust تغییر می‌کند؟

مرحله پنجم: Threat Modeling انجام دهید

Threatهای مربوط به Authentication، Authorization، Business Logic، Data، External Service و Failure State را بررسی کنید.

مرحله ششم: Abuse Case طراحی کنید

فقط User Story ننویسید.

مطرح کنید:

چگونه می‌توان از این Feature سوءاستفاده کرد؟

مرحله هفتم: Secure Pattern انتخاب کنید

اگر Pattern استاندارد وجود دارد از آن استفاده کنید.

Authentication و Cryptography را از صفر طراحی نکنید مگر نیاز واقعی و تخصص لازم وجود داشته باشد.

مرحله هشتم: Failure را طراحی کنید

بپرسید اگر:

Database Down شود،

API پاسخ ندهد،

Authorization Service Fail شود،

Queue پر شود،

Payment Callback دیر برسد،

چه اتفاقی می‌افتد؟

مرحله نهم: Test Case از Threat Model استخراج کنید

هر Risk مهم باید حداقل یک Control و در صورت امکان Test قابل بررسی داشته باشد.

مرحله دهم: Design را با تغییر محصول بازبینی کنید

Threat Model نسخه اول برای همیشه کافی نیست.

Feature جدید می‌تواند Trust Boundary و Attack Surface را تغییر دهد.

اشتباهات رایج در مقابله با Insecure Design

اشتباه اول: «بعداً Security را اضافه می‌کنیم»

بعضی Controlها را می‌توان بعداً اضافه کرد.

اما تغییر Architecture پس از Production معمولاً بسیار سخت‌تر است.

Authentication Model، Multi-tenancy، Data Isolation و Payment Workflow نمونه‌هایی هستند که باید از ابتدا جدی گرفته شوند.

اشتباه دوم: تمرکز فقط روی Vulnerability Scanner

Scanner نمی‌تواند Business Requirement را حدس بزند.

گزارش صفر Vulnerability به معنی Secure Design نیست.

اشتباه سوم: اعتماد به Frontend

Frontend تحت کنترل User است.

Hidden Field، Disabled Button و JavaScript Validation نباید Control امنیتی اصلی باشند.

اشتباه چهارم: فقط طراحی Happy Path

Failure State و Edge Caseها باید بخشی از Design باشند.

اشتباه پنجم: نبود Abuse Case

اگر فقط درباره رفتار User خوب فکر کنید، رفتار مهاجم یا User سوءاستفاده‌گر دیده نمی‌شود.

اشتباه ششم: Security Requirement مبهم

جمله‌ای مثل «سیستم باید امن باشد» Requirement قابل تست نیست.

Requirement باید مشخص و قابل Verification باشد.

اشتباه هفتم: Permissionهای بسیار گسترده

دادن Admin Permission برای ساده‌تر شدن Development، Technical Debt امنیتی ایجاد می‌کند.

اشتباه هشتم: مخلوط کردن Authentication و Authorization

Login موفق به معنی Permission برای همه Resourceها نیست.

اشتباه نهم: اعتماد بیش از حد به شبکه داخلی

Internal Service نیز باید Trust Boundary و Authentication مناسب داشته باشد.

اشتباه دهم: Threat Modeling یک‌باره

Architecture با Featureهای جدید تغییر می‌کند.

Threat Model نیز باید تغییر کند.

چک‌لیست بررسی Insecure Design

Requirement و معماری

• آیا دارایی‌های حساس مشخص شده‌اند؟
• آیا Security Requirementها مستند هستند؟
• آیا Business Risk Profile وجود دارد؟
• آیا Data Flow Diagram تهیه شده است؟
• آیا Trust Boundaryها مشخص هستند؟
• آیا Architecture Review امنیتی انجام شده است؟

Authentication

• آیا Login Flow استاندارد است؟
• آیا MFA برای حساب‌های حساس در نظر گرفته شده؟
• آیا Password Recovery طراحی امن دارد؟
• آیا Re-authentication برای عملیات حساس وجود دارد؟
• آیا Session Lifecycle مشخص است؟

Authorization

• آیا Role و Permission به‌وضوح تعریف شده‌اند؟
• آیا Deny by Default اجرا می‌شود؟
• آیا Object Ownership بررسی می‌شود؟
• آیا Permission سمت Server اعمال می‌شود؟
• آیا Least Privilege رعایت شده؟

Business Logic

• آیا Abuse Caseها شناسایی شده‌اند؟
• آیا عملیات حساس Limit دارند؟
• آیا State Transitionها مشخص هستند؟
• آیا Requestهای تکراری مدیریت می‌شوند؟
• آیا Concurrency Scenarioها بررسی شده‌اند؟
• آیا Valueهای غیرعادی Reject می‌شوند؟

Data

• آیا Sensitive Data مشخص شده؟
• آیا Data Minimization رعایت شده؟
• آیا Tenant Data از هم جدا هستند؟
• آیا Client اجازه تعیین Critical Data را ندارد؟
• آیا Third-party Data قبل از Trust بررسی می‌شود؟

معماری سیستم

• آیا Tierها در صورت نیاز جدا شده‌اند؟
• آیا Componentها حداقل Permission را دارند؟
• آیا Secure Default وجود دارد؟
• آیا Failureها Fail Secure هستند؟
• آیا Attack Surface غیرضروری کاهش یافته؟

Testing

• آیا Unit Test برای Controlهای حیاتی وجود دارد؟
• آیا Integration Test امنیتی وجود دارد؟
• آیا Negative Test انجام می‌شود؟
• آیا Threat Model به Test Case تبدیل شده؟
• آیا Business Logic به‌صورت دستی نیز بررسی می‌شود؟

عملیات و نگهداری

• آیا Logging برای عملیات حساس وجود دارد؟
• آیا Alert برای رفتارهای پرریسک تعریف شده؟
• آیا Incidentها منجر به اصلاح Design می‌شوند؟
• آیا Threat Model بعد از تغییرات عمده به‌روزرسانی می‌شود؟
• آیا Secure Design Patternهای مشترک مستند شده‌اند؟

چگونه یک سایت موجود را از نظر Insecure Design بررسی کنیم؟

سایت‌های قدیمی معمولاً Threat Model اولیه ندارند.

این به معنی غیرممکن بودن بررسی نیست.

می‌توان فرآیند را از Architecture Discovery شروع کرد.

ابتدا Componentها را فهرست کنید:

Frontend

Backend

Database

API

Cache

Queue

Storage

CDN

External Service

Admin Panel

سپس Critical Flowها را مشخص کنید:

Login

Register

Password Reset

Checkout

Payment

Profile Change

File Upload

Admin Operation

Wallet

Ticket

API Integration

برای هر Flow بپرسید:

چه کسی می‌تواند شروعش کند؟

چه Dataهایی وارد می‌شوند؟

کدام Server تصمیم امنیتی می‌گیرد؟

چه Permissionی نیاز است؟

چه Stateهایی وجود دارند؟

چه Limitationی وجود دارد؟

Failure چگونه مدیریت می‌شود؟

آیا Abuse Case وجود دارد؟

این روش می‌تواند Design Debt پروژه‌های Legacy را آشکار کند.

اولویت‌بندی مشکلات طراحی

تمام Design Issueها شدت یکسان ندارند.

Priority باید براساس Risk تعیین شود.

معیارهایی مانند موارد زیر مفید هستند:

Impact

Likelihood

Exposure

Data Sensitivity

Privilege Required

Number of Users

Business Dependency

Exploitability

Detection Difficulty

برای مثال Design Issue در یک صفحه عمومی کم‌اهمیت ممکن است Priority پایین‌تری نسبت به ضعف Tenant Isolation در SaaS داشته باشد.

هدف Security حذف تمام Riskها نیست؛ بلکه رساندن Risk به سطحی قابل قبول برای سازمان است.

آیا Insecure Design فقط مشکل سایت‌های بزرگ است؟

خیر.

حتی سایت‌های کوچک نیز Design Decision دارند.

یک سایت WordPress ساده ممکن است فرم ثبت‌نام اختصاصی، Membership، Upload، Payment یا API داشته باشد.

هر کدام از این قابلیت‌ها می‌تواند نیازمند Security Design باشد.

تفاوت اصلی در Scale است، نه اصل موضوع.

یک سایت کوچک ممکن است Threat Model ساده‌تری داشته باشد، اما همچنان باید مشخص کند:

چه چیزی حساس است؟

چه کسی دسترسی دارد؟

چه اتفاقی در Failure می‌افتد؟

چگونه Abuse محدود می‌شود؟

نقش Penetration Test در شناسایی Insecure Design

Penetration Testing می‌تواند بسیاری از نشانه‌های Insecure Design را آشکار کند، به‌خصوص وقتی Tester فقط Scanner اجرا نکند و Business Logic را نیز تحلیل کند.

مواردی مانند:

Workflow Bypass

Authorization Logic

Rate Limit

State Manipulation

Race Condition

Business Logic Abuse

Tenant Isolation

می‌توانند در تست دستی بررسی شوند.

اما بهترین زمان برای کشف Design Flaw قبل از Production است.

Penetration Test نباید اولین مرحله‌ای باشد که تیم امنیت درباره Architecture اطلاعات کسب می‌کند.

آیا AI می‌تواند Insecure Design را تشخیص دهد؟

ابزارهای AI می‌توانند در Review Architecture، تولید Threat Scenario، تحلیل Requirement و Code Review کمک کنند.

اما AI Business Context کامل سازمان را به‌طور خودکار نمی‌داند.

برای مثال یک Model نمی‌تواند بدون Context مشخص کند:

حداکثر Transfer منطقی چقدر است؟

چه فردی باید Refund را تأیید کند؟

Tenant Isolation چه سطحی نیاز دارد؟

چه Dataهایی از نظر سازمان Critical هستند؟

بنابراین AI می‌تواند Assistant باشد، اما Risk Acceptance و Security Design Decision همچنان نیازمند Context و مسئولیت انسانی هستند.

سوالات متداول درباره Insecure Design

Insecure Design چیست؟

Insecure Design به ضعف‌هایی گفته می‌شود که در معماری، Requirement، Workflow یا Business Logic برنامه وجود دارند و باعث می‌شوند کنترل‌های امنیتی موردنیاز از ابتدا وجود نداشته باشند یا به شکل ناکافی طراحی شوند.

Insecure Design در OWASP Top 10 2025 چه رتبه‌ای دارد؟

Insecure Design در OWASP Top 10 2025 با شناسه A06 در رتبه ششم قرار دارد. این دسته در نسخه ۲۰۲۱ رتبه چهارم را داشت.

تفاوت Insecure Design و Bug چیست؟

Bug معمولاً خطایی در Implementation است، در حالی که Insecure Design می‌تواند حتی زمانی وجود داشته باشد که Code دقیقاً مطابق Specification و بدون Bug نوشته شده باشد.

آیا WAF می‌تواند Insecure Design را برطرف کند؟

خیر. WAF یک Control دفاعی مفید است، اما نمی‌تواند Business Logic، Permission Model یا Workflow ناامن را بازطراحی کند.

Threat Modeling چیست؟

Threat Modeling فرآیندی ساختاریافته برای مدل‌سازی سیستم از دید Security، شناسایی Threatها و مشخص کردن Response یا Control مناسب است. بهتر است این فرآیند در مراحل ابتدایی SDLC انجام شود و با تغییر Architecture به‌روزرسانی شود.

Secure by Design چیست؟

Secure by Design یعنی امنیت از مراحل اولیه Requirement و Architecture بخشی از محصول باشد، نه اینکه پس از Development به‌عنوان یک Feature اضافی نصب شود.

Secure by Default چیست؟

Secure by Default یعنی Software با تنظیمات اولیه‌ای عرضه یا Deploy شود که تا حد ممکن حالت امن داشته باشند و User مجبور نباشد برای رسیدن به حداقل Security تنظیمات پیچیده‌ای انجام دهد.

Business Logic Vulnerability چیست؟

ضعفی است که از قوانین یا Workflowهای ناقص کسب‌وکار ناشی می‌شود و ممکن است به User اجازه دهد با استفاده از Featureهای قانونی برنامه نتیجه‌ای غیرمجاز یا ناخواسته ایجاد کند.

Abuse Case چیست؟

Abuse Case سناریویی است که بررسی می‌کند چگونه ممکن است یک قابلیت قانونی سیستم برخلاف هدف طراحی مورد سوءاستفاده قرار گیرد.

آیا Code Review می‌تواند Insecure Design را پیدا کند؟

گاهی بله، اما همیشه نه. بسیاری از Design Flawها فقط با شناخت Architecture، Business Requirement و Threat Model قابل تشخیص هستند.

آیا SAST برای Insecure Design کافی است؟

خیر. SAST برای شناسایی بسیاری از Code Patternهای خطرناک مفید است، اما نمی‌تواند تمام مشکلات Business Logic و Architecture را تشخیص دهد.

Insecure Design در وردپرس هم وجود دارد؟

بله. Plugin اختصاصی، REST API، Role، Membership، WooCommerce Extension، File Upload و Integrationهای خارجی می‌توانند Design Flaw داشته باشند.

چگونه از Insecure Design جلوگیری کنیم؟

مهم‌ترین روش‌ها شامل تعریف Security Requirement، Threat Modeling، Abuse Case، Secure Design Pattern، Least Privilege، Secure Defaults، Fail Secure، Negative Testing و Secure Development Lifecycle هستند.

تفاوت Secure Coding و Secure Design چیست؟

Secure Coding روی نحوه نوشتن Code امن تمرکز دارد، در حالی که Secure Design قبل و فراتر از Code به Architecture، Requirement، Workflow و Controlهای سیستم می‌پردازد.

آیا طراحی ناامن با Patch امنیتی برطرف می‌شود؟

گاهی اصلاح Design در قالب Patch قابل Deploy است، اما ممکن است نیازمند تغییر Architecture، Database، API یا Workflow باشد. بنابراین معمولاً اصلاح آن پیچیده‌تر از یک Bug ساده است.

آیا Insecure Design همیشه قابل Exploit است؟

هر Design Flaw الزاماً به Exploit عملی منجر نمی‌شود. Risk به Exposure، Business Context، Controlهای دیگر و توانایی مهاجم بستگی دارد. با این حال نبود Control مناسب می‌تواند احتمال و Impact سوءاستفاده را افزایش دهد.

جمع‌بندی

Insecure Design یکی از مهم‌ترین مفاهیم امنیت نرم‌افزار مدرن است، زیرا نشان می‌دهد Security فقط مسئله Code نیست.

یک برنامه ممکن است:

SQL Injection نداشته باشد،

XSS نداشته باشد،

HTTPS داشته باشد،

WAF داشته باشد،

Dependencyهای به‌روز داشته باشد،

و همچنان از نظر Design ناامن باشد.

اگر Business Logic بدون Limit باشد، Account Recovery ضعیف طراحی شده باشد، Trust Boundary اشتباه تعریف شده باشد، Tenant Isolation کافی نباشد یا Failure State به شکل خطرناک عمل کند، Application همچنان در معرض Risk قرار دارد.

مهم‌ترین تفاوت Insecure Design با بسیاری از Vulnerabilityهای دیگر این است که Root Cause آن اغلب قبل از نوشتن Code شکل می‌گیرد.

به همین دلیل راهکار اصلی نیز باید قبل از Coding شروع شود.

Security Requirement باید در کنار Functional Requirement نوشته شود.

دارایی‌های مهم باید شناسایی شوند.

Business Risk باید مشخص شود.

Threat Modeling باید Critical Flowها را بررسی کند.

Trust Boundaryها باید تعریف شوند.

Use Case در کنار Abuse Case نوشته شود.

Failure State باید طراحی شود.

Least Privilege، Deny by Default، Defense in Depth و Secure Default باید در Architecture حضور داشته باشند.

پس از آن Unit Test، Integration Test، Negative Test، Code Review، SAST، DAST و Penetration Testing می‌توانند بررسی کنند که Design امن واقعاً به‌درستی Implementation شده است.

NIST در SSDF نیز بر ادغام Practiceهای توسعه امن در SDLC تأکید می‌کند تا نه‌فقط Vulnerabilityهای موجود کاهش پیدا کنند، بلکه Root Cause ایجاد آن‌ها نیز اصلاح شود.

برای سایت‌های وردپرسی، فروشگاه‌های WooCommerce، APIها، SaaS، سامانه‌های مالی و Web Applicationهای اختصاصی نیز همین اصل برقرار است.

نصب Plugin امنیتی یا WAF جای Architecture امن را نمی‌گیرد.

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

در نهایت می‌توان مفهوم Insecure Design را در یک جمله خلاصه کرد:

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