OWASP Top ۱۰ ۲۰۲۵؛ آسیب‌پذیری‌های وب و روش تست

تصور کنید کاربر فروشگاه فقط با عوض‌کردن شناسهٔ سفارش، فاکتور مشتری دیگری را می‌بیند. اسکنر شاید هیچ خطای فنی آشکاری گزارش نکند، اما کنترل دسترسی شکسته است و یک رخداد واقعی امنیتی شکل گرفته. OWASP Top ۱۰ دقیقاً برای دیدن چنین الگوهای پرخطر به تیم‌های محصول، توسعه و QA زبان مشترک می‌دهد.

این راهنما فهرست رسمی OWASP Top 10:2025 را به تست‌های عملی و کم‌خطر تبدیل می‌کند: هر دسته چه معنایی دارد، در یک وب‌اپلیکیشن ایرانی چگونه دیده می‌شود، چه شاهدی باید جمع شود و چه چیزی را نباید روی محیط عملیاتی امتحان کرد. تمرکز مقاله روی آزمون مجاز است؛ نه ارائهٔ دستور بهره‌برداری از سامانه‌های واقعی.

خلاصهٔ سریع: Top ۱۰ یک سند آگاهی‌بخش دربارهٔ ده خانوادهٔ مهم ریسک است، نه گواهی امنیت و نه چک‌لیست کامل تست. برای استخراج الزام از OWASP ASVS 5.0.0 و برای روش آزمون از OWASP WSTG استفاده کنید. اگر به نقشهٔ کامل فرایند نیاز دارید، راهنمای تست امنیت نرم‌افزار مکمل این مقاله است.

OWASP Top ۱۰:۲۰۲۵ چیست و چه چیزی نیست؟

OWASP Top 10:2025 سند آگاهی‌بخشی است که بر پایهٔ داده‌های مشارکت‌کنندگان و نظر جامعهٔ امنیت، ده خانواده از ریسک‌های مهم برنامه‌های وب را برجسته می‌کند. دسته‌ها چندین ضعف از فهرست CWE را زیر یک عنوان جمع می‌کنند؛ بنابراین «Injection» یک باگ واحد و «Broken Access Control» یک تست منفرد نیست.

• برای آگاهی و اولویت اولیه مناسب است: تیم‌ها دربارهٔ ریسک‌ها واژگان مشترک پیدا می‌کنند.
• جایگزین مدل تهدید نیست: دارایی‌ها، نقش‌ها، مرزهای اعتماد و سوءاستفاده‌های خاص کسب‌وکار شما را نمی‌شناسد.
• جایگزین ASVS و WSTG نیست: Top ۱۰ می‌گوید کجاها مهم‌اند؛ ASVS الزام قابل‌راستی‌آزمایی و WSTG روش آزمون می‌دهد.
• مدرک «امن‌بودن» نیست: پوشش ده دسته به معنای پوشش همهٔ ضعف‌ها، APIها، موبایل، زیرساخت و منطق کسب‌وکار نیست.
• رتبهٔ دسته، شدت هر یافته نیست: یک یافتهٔ A01 ممکن است کم‌اثر یا بحرانی باشد؛ شدت را باید با دارایی، قابلیت بهره‌برداری و اثر واقعی سنجید.

چه چیزهایی از نسخهٔ ۲۰۲۱ به ۲۰۲۵ تغییر کرد؟

نسخهٔ ۲۰۲۵ فقط جابه‌جایی رتبه‌ها نیست. OWASP اعلام کرده دو دستهٔ جدید و یک ادغام رخ داده است. مهم‌ترین تغییرهای اجرایی برای تیم QA عبارت‌اند از:

• A01 Broken Access Control همچنان رتبهٔ اول است و SSRF که در ۲۰۲۱ دستهٔ جداگانه بود، اکنون در همین خانواده قرار گرفته است.
• A02 Security Misconfiguration از رتبهٔ پنجم به دوم آمده؛ چون بخش بیشتری از رفتار سامانه‌ها به تنظیمات وابسته شده است.
• A03 Software Supply Chain Failures دامنهٔ «اجزای آسیب‌پذیر و قدیمی» را به وابستگی‌ها، سامانهٔ Build و زیرساخت توزیع گسترش می‌دهد.
• A07 Authentication Failures نام دقیق‌تری نسبت به «Identification and Authentication Failures» دارد.
• A09 Security Logging & Alerting Failures روی هشدار قابل‌اقدام تأکید می‌کند؛ ثبت لاگی که دیده نشود کافی نیست.
• A10 Mishandling of Exceptional Conditions تازه است و خطاهای منطقی، مدیریت نادرست استثناها و Fail-open را پوشش می‌دهد.

در نتیجه، چک‌لیستی که فقط نام‌های ۲۰۲۱ را تکرار کند، پوشش نسخهٔ جدید محسوب نمی‌شود. مرجع جزئیات این تغییرها، مقدمهٔ رسمی نسخهٔ ۲۰۲۵ است.

پیش‌نیاز تست امن: مجوز، دامنه و شرایط توقف

پیش از هر تست امنیتی باید مجوز کتبی و Rules of Engagement داشته باشید. حتی آزمون ظاهراً ساده می‌تواند حساب را قفل کند، هشدار تیم عملیات را فعال کند یا دادهٔ مشتری را تغییر دهد. برای محیط Production فقط تست‌های صریحاً مجاز و کم‌خطر را اجرا کنید.

• دامنهٔ دقیق شامل میزبان، API، نقش کاربری، Tenant و زمان آزمون را بنویسید.
• حساب‌ها و داده‌های آزمایشی قابل‌شناسایی بسازید؛ از دادهٔ واقعی مشتری استفاده نکنید.
• محدودیت نرخ، سقف درخواست و مسیر تماس اضطراری را مشخص کنید.
• شرایط توقف مانند افزایش خطا، افت سرویس، مشاهدهٔ دادهٔ واقعی یا اثر مالی را از قبل توافق کنید.
• بکاپ، بازگردانی تراکنش و پاک‌سازی دادهٔ تست را مالک‌دار کنید.
• شاهد را با حذف توکن، رمز، دادهٔ شخصی و اطلاعات حساس نگه دارید.

اگر تست به بار، تاب‌آوری یا اختلال نزدیک می‌شود، آن را با برنامهٔ تست غیرکارکردی و تیم عملیات هماهنگ کنید؛ تست امنیت مجوزی برای ایجاد اختلال نیست.

ده ریسک OWASP Top ۱۰:۲۰۲۵ و روش تست هرکدام

A01:۲۰۲۵ ـ Broken Access Control | کنترل دسترسی شکسته

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

مثال فروشگاهی: خریدار با تغییر شناسهٔ سفارش، فاکتور خریدار دیگر را می‌بیند؛ فروشنده گزارش فروش Tenant دیگری را می‌گیرد؛ یا URL ادمین برای نقش پشتیبانی نیز پاسخ موفق می‌دهد. SSRF نیز در نسخهٔ ۲۰۲۵ زیر این دسته آمده است.

تست امن: با دو حساب آزمایشی A و B، ماتریس «نقش × عمل × مالک منبع» بسازید. درخواست مجاز A را با شناسهٔ منبع B تکرار کنید و انتظار رد یکنواخت داشته باشید. فقط مقصدهای شبکه‌ای Canary و ازپیش‌توافق‌شده را برای بررسی درخواست سمت سرور به‌کار ببرید؛ سراغ آدرس‌های داخلی یا سرویس ابری واقعی نروید.

شاهد و کنترل: کد وضعیت، بدنهٔ حذف‌شده از دادهٔ حساس، شناسهٔ Trace و تفاوت پاسخ دو نقش را ثبت کنید. کنترل سمت سرور، Deny by default، جداسازی Tenant، اعتبارسنجی مالکیت منبع و تست رگرسیون مجوزها ضروری‌اند. برای پوشش ورودی‌ها و مجوزهای endpointها، راهنمای تست API را ببینید.

A02:۲۰۲۵ ـ Security Misconfiguration | پیکربندی امنیتی نادرست

مسئله: تنظیم پیش‌فرض ناامن، Debug فعال، مجوز بیش‌ازحد، CORS باز، Headerهای نامناسب، پیام خطای افشاگر یا سرویس بلااستفاده سطح حمله را بزرگ می‌کند.

مثال فروشگاهی: پنل مدیریت روی اینترنت عمومی است، فایل تنظیمات قدیمی قابل دانلود است، پاسخ خطا Stack Trace نشان می‌دهد، یا Origin نامعتبر می‌تواند پاسخ دارای اعتبارنامه را بخواند.

تست امن: خط مبنای پیکربندی نسخه‌شده را با محیط بررسی‌شده مقایسه کنید. Headerها، Cookieها، CORS، TLS، صفحات خطا، Directory listing، endpointهای سلامت و قابلیت‌های مدیریتی را بدون تغییر تنظیمات بسنجید. تفاوت Dev، Staging و Production را نیز بررسی کنید.

شاهد و کنترل: یک نمونهٔ پاسخ Sanitized و مسیر پیکربندی مالک‌دار کافی است. Hardening خودکار، Infrastructure as Code، حذف قابلیت‌های غیرضروری، مدیریت Secret و آزمون Drift از اصلاح‌های پایدارند؛ پنهان‌کردن Banner به‌تنهایی رفع ریشه‌ای نیست.

A03:۲۰۲۵ ـ Software Supply Chain Failures | شکست زنجیرهٔ تأمین نرم‌افزار

مسئله: ریسک فقط «نسخهٔ قدیمی کتابخانه» نیست؛ منبع وابستگی، Lockfile، CI/CD، Runner، Artifact، امضا و کانال انتشار نیز جزو زنجیرهٔ اعتمادند.

مثال فروشگاهی: پکیج همنام از Registry عمومی جای وابستگی داخلی را می‌گیرد، Runner مشترک Secret انتشار را افشا می‌کند، یا Artifact بدون منشأ قابل‌راستی‌آزمایی وارد Production می‌شود.

تست امن: موجودی وابستگی مستقیم و انتقالی را استخراج کنید؛ Lockfile و Registry مجاز را کنترل کنید؛ دسترسی Pipeline، جداسازی Runner، Pin کردن Actionها، مسیر تأیید Artifact و امکان بازتولید Build را بررسی کنید. در یک محیط تست، Artifact بی‌امضا یا از منشأ غیرمجاز باید پیش از استقرار رد شود.

شاهد و کنترل: SBOM نسخه‌دار، هش یا امضای Artifact، گزارش منشأ، مالک استثناها و زمان رفع وابستگی آسیب‌پذیر را نگه دارید. اسکن SCA بدون سیاست پذیرش، مالک و مسیر Patch فقط تولید هشدار می‌کند. کنترل‌های زنجیرهٔ تأمین باید در Continuous Testing و CI/CD قرار گیرند.

A04:۲۰۲۵ ـ Cryptographic Failures | شکست‌های رمزنگاری

مسئله: دادهٔ حساس در انتقال یا ذخیره محافظت کافی ندارد، الگوریتم یا شیوهٔ استفاده نامناسب است، کلیدها درست مدیریت نمی‌شوند یا محرمانگی داده بیش از عمر کلید فرض شده است.

مثال فروشگاهی: توکن نشست در Cookie بدون Secure منتقل می‌شود، دادهٔ احراز هویت در Log می‌نشیند، کلید در مخزن کد قرار دارد یا نسخهٔ پشتیبان بدون حفاظت در دسترس نقش غیرمجاز است.

تست امن: طبقه‌بندی داده را با مسیر واقعی داده از مرورگر تا API، Queue، Log، Cache و Backup تطبیق دهید. TLS، ویژگی‌های Cookie، ذخیرهٔ Token، چرخش و ابطال کلید و رفتار در زمان منقضی‌شدن گواهی را در محیط کنترل‌شده بررسی کنید.

شاهد و کنترل: نام داده، محل، مالک، مدت نگهداری و کنترل حفاظتی را در یک Data Flow ثبت کنید؛ خود Secret را ضمیمه نکنید. از کتابخانه‌های معتبر، الگوریتم‌های استاندارد، Vault یا KMS، چرخش کلید و حداقل‌سازی داده استفاده شود. رمزگذاری خانگی یا صرفاً Base64 کنترل امنیتی نیست.

A05:۲۰۲۵ ـ Injection | تزریق

مسئله: دادهٔ کنترل‌نشده وارد Query، Command، Template، LDAP یا مرورگر می‌شود و به‌جای داده، به‌عنوان دستور یا کد تفسیر می‌گردد. XSS نیز در این خانواده قرار دارد.

مثال فروشگاهی: فیلتر گزارش مستقیماً به Query متصل است، نام محصول بدون Encode متناسب با Context در پنل نمایش داده می‌شود، یا ورودی عملیات فایل به Command سیستم‌عامل می‌رسد.

تست امن: از رشته‌های بی‌ضرر و قابل‌ردیابی برای تشخیص تغییر تفسیر استفاده کنید؛ پاسخ، Log و Query plan را در محیط تست ببینید. پوشش Source-to-sink در بازبینی کد را با آزمون رفتاری ترکیب کنید. از Payload مخرب، استخراج داده، اجرای دستور یا ایجاد ماندگاری خودداری کنید.

شاهد و کنترل: Context ورودی، محل Sink و تغییر رفتاری کم‌خطر را ثبت کنید. Query پارامتری، API امن، Allowlist متناسب با دامنه، Output encoding متناسب با Context و حذف Shell غیرضروری کنترل‌های اصلی‌اند. یک WAF می‌تواند لایهٔ کمکی باشد، نه جایگزین اصلاح کد.

A06:۲۰۲۵ ـ Insecure Design | طراحی ناامن

مسئله: حتی پیاده‌سازی بدون باگ هم ممکن است کنترل لازم برای یک تهدید را اصلاً طراحی نکرده باشد. این دسته بر مدل تهدید، Abuse case، محدودیت کسب‌وکار و معماری امن تمرکز دارد.

مثال فروشگاهی: فرایند بازگشت وجه هیچ تأیید دومرحله‌ای یا سقف تجمعی ندارد؛ کد تخفیف بدون محدودیت ترکیب می‌شود؛ یا تغییر شمارهٔ حساب فروشنده بدون بازاحراز هویت ممکن است.

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

شاهد و کنترل: پیوند «تهدید → الزام امنیتی → کنترل → تست → مالک» را نگه دارید. جداسازی وظایف، تأیید مرحله‌ای، محدودیت تجمعی، Idempotency و طراحی Fail-safe باید پیش از کدنویسی وارد Acceptance Criteria شوند.

A07:۲۰۲۵ ـ Authentication Failures | شکست احراز هویت

مسئله: ثبت‌نام، ورود، بازیابی حساب، MFA، نشست و خروج یک زنجیره‌اند. ضعف در هر حلقه می‌تواند هویت را قابل‌تصاحب کند.

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

تست امن: با حساب‌های آزمایشی، چرخهٔ کامل ایجاد، ورود، قفل یا Rate limit، بازیابی، تغییر عامل، خروج و ابطال نشست را بررسی کنید. تفاوت پاسخ نباید فهرست کاربران بسازد. آزمون نرخ فقط با سقف توافق‌شده و روی محیط مناسب اجرا شود.

شاهد و کنترل: زمان ایجاد و ابطال Token، وضعیت نشست و پاسخ‌های هم‌ارز را ثبت کنید. MFA مقاوم در برابر فیشینگ در سناریوهای پرخطر، مدیریت استاندارد نشست، Hash مناسب رمز، تشخیص اعتبارنامهٔ افشاشده و بازاحراز هویت برای عملیات حساس مهم‌اند. مدل‌کردن این چرخه با تست انتقال حالت خطاهای بین مراحل را آشکار می‌کند.

A08:۲۰۲۵ ـ Software or Data Integrity Failures | شکست یکپارچگی نرم‌افزار یا داده

مسئله: سامانه به کد، به‌روزرسانی یا داده‌ای اعتماد می‌کند که اصالت و تمامیتش را راستی‌آزمایی نکرده است. تفاوت با A03 این است که اینجا شکست مرز اعتماد در مصرف Artifact یا داده محور است؛ A03 کل اکوسیستم تأمین و ساخت را می‌بیند.

مثال فروشگاهی: Callback پرداخت فقط به فیلد «موفق» در بدنه اعتماد می‌کند، Update بدون امضا پذیرفته می‌شود، یا دادهٔ Serial شده از منبع غیرقابل‌اعتماد بازیابی می‌گردد.

تست امن: در Sandbox درگاه، Replay، پیام تکراری، ترتیب متفاوت و دستکاری بی‌ضرر دادهٔ تست را بررسی کنید. سرویس باید امضا یا اصالت، مبلغ، ارز، شناسهٔ پذیرنده و یکتایی تراکنش را در سمت سرور تأیید کند.

شاهد و کنترل: نتیجهٔ اعتبارسنجی، شناسهٔ همبستگی و رفتار در پیام تکراری را ثبت کنید. امضای دیجیتال، منشأ قابل‌اعتماد، Hash، Nonce، Idempotency و عدم Deserialize ناامن از کنترل‌های کلیدی‌اند.

A09:۲۰۲۵ ـ Security Logging and Alerting Failures | شکست ثبت رخداد و هشدار

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

مثال فروشگاهی: تغییر حساب بانکی فروشنده بدون Audit trail است؛ چند شکست ورود هیچ هشدار قابل‌اقدامی نمی‌سازد؛ یا Log شامل Token کامل و اطلاعات کارت است.

تست امن: یک رویداد مجاز و یک رویداد ردشدهٔ آزمایشی ایجاد کنید و مسیر «تولید → انتقال → ذخیره → Rule → هشدار → Runbook» را دنبال کنید. ساعت‌ها، Correlation ID، نقش، هدف و نتیجه باید قابل اتصال باشند؛ دادهٔ حساس نباید در Log باشد.

شاهد و کنترل: زمان رسیدن هشدار، مقصد، مالک پاسخ و نتیجهٔ Runbook را ثبت کنید. Log ساخت‌یافته و مقاوم در برابر دستکاری، همگام‌سازی زمان، حداقل‌سازی داده، Rule قابل‌آزمون، On-call و تمرین دوره‌ای لازم‌اند. تعداد Log معیار موفقیت نیست؛ هشدار باید به تصمیم منجر شود.

A10:۲۰۲۵ ـ Mishandling of Exceptional Conditions | مدیریت نادرست شرایط استثنایی

مسئله: Timeout، خطای وابستگی، مقدار غیرمنتظره، شکست جزئی یا رقابت هم‌زمان به حالت ناسازگار، افشای جزئیات یا Fail-open منجر می‌شود.

مثال فروشگاهی: درگاه پاسخ نامشخص می‌دهد اما سفارش «پرداخت‌شده» می‌شود؛ سرویس مجوز در دسترس نیست و سیستم اجازه می‌دهد؛ Worker پس از Retry دوباره موجودی را کم می‌کند؛ یا خطای محاسبه مبلغ منفی پذیرفته می‌شود.

تست امن: در محیط کنترل‌شده با Stub یا Fault injection، Timeout، پاسخ ناقص، تکرار، ترتیب متفاوت، مقدار مرزی و قطع وابستگی را ایجاد کنید. سیستم باید به حالت امن و قابل‌بازیابی برود، نه اینکه موفقیت را حدس بزند. تست Chaos روی Production بدون مجوز و حفاظ‌های عملیاتی مناسب ممنوع است.

شاهد و کنترل: حالت قبل و بعد، اثر جانبی، Retry count و Trace را نگه دارید. Timeout صریح، Circuit breaker، تراکنش یا جبران، Idempotency، Dead-letter queue، اعتبارسنجی invariant و Fail-closed برای تصمیم امنیتی از کنترل‌های مهم‌اند.

چگونه Top ۱۰ را به برنامهٔ تست قابل‌ردیابی تبدیل کنیم؟

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

1. دارایی و اثر را مشخص کنید: حساب، سفارش، کیف پول، فایل، دادهٔ شخصی یا دسترسی مدیریتی.
2. مرز اعتماد را رسم کنید: مرورگر، API Gateway، سرویس، Queue، درگاه پرداخت، CI/CD و سرویس ثالث.
3. الزام قابل‌آزمون بنویسید: به‌جای «A01 را تست کن» بنویسید «فروشنده فقط سفارش‌های Tenant خودش را می‌خواند».
4. مرجع بدهید: الزام را به نسخهٔ مشخص ASVS و سناریوی نسخه‌دار WSTG نگاشت کنید.
5. روش و محیط را تعیین کنید: بازبینی طراحی، SAST، SCA، DAST، تست API، تست دستی یا ترکیبی.
6. Oracle را روشن کنید: پاسخ امن مورد انتظار، Log، هشدار، عدم اثر جانبی و حالت نهایی.
7. شاهد حداقلی جمع کنید: Request/response حذف‌شده از Secret، Trace ID، تصویر و نسخهٔ Build.
8. رگرسیون را خودکار کنید: به‌ویژه مجوزها، Callbackها، پیکربندی و رفتارهای استثنایی پایدار.

WSTG برای روش‌های آزمون وب مناسب است و OWASP Cheat Sheet Series کنترل‌های پیاده‌سازی را تکمیل می‌کند. هنگام ارجاع، شمارهٔ نسخه را ثبت کنید؛ زیرا شناسه‌ها در نسخه‌های بعدی ممکن است تغییر کنند.

نمونهٔ عملی: فروشگاه چندفروشنده‌ای ایرانی

فرض کنید محصول نقش‌های خریدار، فروشنده، پشتیبانی، مالی و مدیر دارد؛ پرداخت از درگاه ثالث می‌آید و گزارش‌ها فایل خروجی تولید می‌کنند. یک بستهٔ تست کوچک اما مؤثر می‌تواند چنین باشد:

• A01: هر نقش برای خواندن، ویرایش و خروجی‌گرفتن منابع خود و دیگری بررسی شود.
• A02: Debug، CORS، Cookie، صفحات خطا و endpointهای مدیریتی در Production با Baseline مقایسه شوند.
• A03: وابستگی‌ها، Lockfile، Registry و مسیر امضاشدهٔ Build تا Deploy ردیابی شود.
• A04: مسیر دادهٔ هویتی و مالی در Transit، Log، Cache و Backup بررسی شود.
• A05: ورودی جست‌وجو، گزارش و پنل محتوا در Context واقعی و با ورودی بی‌ضرر آزمون شود.
• A06: سوءاستفاده از تخفیف، بازگشت وجه و تغییر حساب بانکی مدل شود.
• A07: بازیابی حساب، تغییر شماره همراه، ابطال نشست و عملیات حساس پوشش داده شود.
• A08: Callback پرداخت از نظر اصالت، مبلغ، Replay و Idempotency کنترل شود.
• A09: تغییر دادهٔ مالی و شکست‌های ورود باید Audit trail و هشدار مالک‌دار بسازند.
• A10: Timeout درگاه، قطع Inventory و Retry Worker نباید سفارش یا موجودی ناسازگار بسازد.

این بسته هنوز تست نفوذ کامل نیست، اما ریسک‌های عمومی را به جریان‌های پولی و داده‌ای واقعی محصول وصل می‌کند؛ همان چیزی که یک اسکن عمومی به‌تنهایی نمی‌بیند.

ماتریس مجوز؛ ساده‌ترین تست برای کشف A01

برای هر منبع مهم یک جدول با سطرهای نقش و ستون‌های عمل بسازید. در هر خانه سه حالت «مجاز»، «غیرمجاز» و «مشروط» بنویسید. شرط ممکن است مالکیت، وضعیت سفارش، سقف مبلغ یا تأیید دوم باشد.

نقش	مشاهدهٔ سفارش خود	مشاهدهٔ سفارش دیگری	بازگشت وجه	تغییر حساب بانکی
خریدار	مجاز	غیرمجاز	درخواست مشروط	نامرتبط
فروشنده	مجاز در Tenant خود	غیرمجاز	مشروط به سیاست	با بازاحراز هویت
پشتیبانی	فقط نیاز کاری	مشروط و ثبت‌شده	غیرمجاز	غیرمجاز
مالی	حداقل دادهٔ لازم	مشروط	مجاز با سقف	غیرمجاز

سپس برای هر خانه حداقل یک تست مثبت و یک تست منفی بسازید. پاسخ ۴۰۳ یا ۴۰۴ به‌تنهایی Oracle کافی نیست؛ بررسی کنید داده، اثر جانبی، Cache و Log نیز مجاز باقی مانده‌اند.

گزارش یک یافتهٔ امنیتی چه اجزایی دارد؟

عنوان «OWASP A01 پیدا شد» برای اصلاح کافی نیست. گزارش باید قابل‌بازتولید، کم‌خطر و متصل به اثر کسب‌وکار باشد:

• دارایی، محیط، نسخهٔ Build و نقش آزمایشی؛
• پیش‌شرط و مراحل بازتولید با دادهٔ ساختگی؛
• رفتار مورد انتظار و رفتار مشاهده‌شده؛
• شاهد Sanitized و شناسهٔ Trace، بدون Secret یا دادهٔ مشتری؛
• اثر فنی و اثر کسب‌وکار با فرض‌های روشن؛
• نگاشت به OWASP، CWE و الزام نسخه‌دار ASVS در صورت امکان؛
• راه اصلاح ریشه‌ای، کنترل موقت، مالک و مهلت؛
• تست Retest و Regression پس از اصلاح.

دستهٔ OWASP شدت نیست. امتیاز CVSS نیز باید با زمینهٔ کسب‌وکار، دسترسی لازم، دامنهٔ اثر و حساسیت دارایی ترکیب شود. برای قالب دقیق، مقالهٔ گزارش باگ حرفه‌ای را به گزارش امنیتی تطبیق دهید.

برنامهٔ ۳۰روزه برای شروع تست OWASP Top ۱۰

هفتهٔ اول: شناخت دامنه و ریسک

• مالک محصول، AppSec، QA، توسعه و عملیات را مشخص کنید.
• دارایی‌ها، نقش‌ها، جریان داده و سرویس‌های ثالث را فهرست کنید.
• مجوز، محیط، حساب تست، نرخ و شرایط توقف را تصویب کنید.
• نسخهٔ مرجع OWASP، ASVS و WSTG را در Test Plan ثبت کنید.

هفتهٔ دوم: طراحی پوشش

• ماتریس مجوز و مدل حالت جریان‌های ورود، سفارش و پرداخت را بسازید.
• برای ده دسته، الزام‌های مرتبط و موارد نامرتبط را با دلیل مشخص کنید.
• ابزار را بر اساس پوشش انتخاب کنید؛ نه بر اساس ادعای تبلیغاتی «پوشش کامل Top ۱۰».

هفتهٔ سوم: اجرای کنترل‌شده

• بازبینی طراحی و کد را با SAST، SCA، DAST و تست دستی ترکیب کنید.
• یافته‌ها را سریع Triage کنید تا False positive و موارد تکراری حذف شوند.
• برای هر یافتهٔ معتبر، اثر، مالک، مهلت و کنترل موقت تعریف کنید.

هفتهٔ چهارم: اصلاح و رگرسیون

• اصلاح را در همان Context و یک Context مجاور دوباره تست کنید.
• رگرسیون‌های پایدار را وارد Pipeline کنید؛ تست‌های مخرب را زمان‌بندی و محدود نگه دارید.
• نرخ بازگشت یافته، زمان رفع بر اساس ریسک و پوشش الزام‌های حیاتی را مرور کنید.
• ریسک پذیرفته‌شده باید مالک، دلیل، کنترل جبرانی و تاریخ بازبینی داشته باشد.

اشتباه‌های رایج در استفاده از OWASP Top ۱۰

• Top ۱۰ را چک‌لیست انطباق فرض‌کردن: نتیجه، تیک سبز بدون پوشش منطق محصول است.
• سپردن کل کار به اسکنر: ابزار معمولاً مجوز افقی، طراحی ناامن و اثر کسب‌وکار را کامل نمی‌بیند.
• آزمون Production بدون قواعد درگیری: ممکن است از خود ضعف، آسیب‌زاتر باشد.
• گزارش Payload بدون اثر و شاهد: توسعه‌دهنده نمی‌داند کدام مرز اعتماد باید اصلاح شود.
• اصلاح نشانه به‌جای علت: بستن یک URL یا افزودن Regex ممکن است مسیرهای مشابه را باز بگذارد.
• اتکا به رتبهٔ A01 تا A10 برای شدت: اولویت هر یافته باید مستقل و زمینه‌محور باشد.
• فراموش‌کردن Retest: بسته‌شدن Ticket اثبات اصلاح نیست.
• نادیده‌گرفتن زنجیرهٔ تأمین و شرایط استثنایی: چک‌لیست‌های ۲۰۲۱ این دو تغییر مهم ۲۰۲۵ را از دست می‌دهند.

چک‌لیست خروجی قابل‌قبول

• نسخهٔ OWASP Top ۱۰ در گزارش نوشته شده است.
• برای هر دسته، ارتباط یا عدم ارتباط آن با محصول مستند است.
• الزام‌ها به دارایی، نقش و جریان واقعی وصل شده‌اند.
• تست‌ها مجوز، محیط، نرخ و شرایط توقف دارند.
• شاهدها از Secret و دادهٔ شخصی پاک شده‌اند.
• یافته‌ها اثر، مالک، مهلت و تست اصلاح دارند.
• کنترل‌های کلیدی به ASVS و روش‌ها به WSTG نسخه‌دار ارجاع دارند.
• ماتریس مجوز، جریان‌های حالت و رفتارهای استثنایی پوشش داده شده‌اند.
• رگرسیون‌های مناسب وارد Pipeline شده‌اند.
• ریسک‌های خارج از Top ۱۰ نیز از مدل تهدید و معماری استخراج شده‌اند.

سوالات متداول درباره OWASP Top ۱۰:۲۰۲۵

آیا OWASP Top ۱۰ استاندارد تست امنیت است؟

خیر؛ OWASP آن را سند آگاهی‌بخشی می‌نامد. برای الزام‌های قابل‌راستی‌آزمایی از ASVS و برای روش‌های آزمون وب از WSTG استفاده کنید. Top ۱۰ نقطهٔ شروع اولویت‌گذاری است، نه پایان برنامهٔ امنیت.

تفاوت اصلی نسخهٔ ۲۰۲۱ و ۲۰۲۵ چیست؟

در ۲۰۲۵ زنجیرهٔ تأمین نرم‌افزار به‌صورت گسترده‌تر در A03 آمده، مدیریت شرایط استثنایی A10 جدید است، SSRF در A01 ادغام شده و نام A09 بر هشداردهی تأکید می‌کند. چند دسته نیز رتبه یا نامشان تغییر کرده است.

آیا یک اسکنر می‌تواند همهٔ OWASP Top ۱۰ را تست کند؟

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

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

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

هر چند وقت یک‌بار تست OWASP Top ۱۰ را تکرار کنیم؟

یک فاصلهٔ ثابت برای همه مناسب نیست. رگرسیون‌های کم‌خطر باید با تغییر مرتبط یا در Pipeline اجرا شوند؛ بازبینی عمیق پس از تغییر معماری، ورود سرویس ثالث، تغییر احراز هویت، رخداد امنیتی یا انتشار مهم تکرار شود. یافته‌های قبلی نیز تا تأیید Retest باز محسوب شوند.

منابع و یادداشت بازبینی

مبنای این راهنما نسخهٔ منتشرشدهٔ OWASP Top ۱۰:۲۰۲۵، ASVS ۵.۰.۰ و صفحهٔ رسمی WSTG است. آخرین بازبینی محتوایی: ۱۵ مرداد ۱۴۰۵. نمونه‌ها آموزشی و برای محیط دارای مجوز نوشته شده‌اند. OWASP دسته‌ها را در آینده به‌روزرسانی می‌کند؛ بنابراین در Test Plan همیشه شمارهٔ نسخه را ثبت کنید.

جمع‌بندی: ارزش OWASP Top ۱۰ در حفظ‌کردن ده نام نیست؛ در تبدیل ریسک عمومی به الزام، آزمون، شاهد و اصلاح قابل‌ردیابی است. وقتی تیم برای کنترل دسترسی ماتریس دارد، برای پرداخت حالت‌های استثنایی را می‌آزماید، زنجیرهٔ Build را راستی‌آزمایی می‌کند و هشدار را تا Runbook دنبال می‌کند، سند آگاهی‌بخش به یک برنامهٔ امنیتی واقعی تبدیل می‌شود.