OWASP Top 10 مرجع استانداردِ ردهبندی ریسک در امنیت وب است و نسخهی ۲۰۲۵ — هشتمین نسخه — اکنون منتشر شده و جایگزین نسخهی ۲۰۲۱ است. اگر چک‌لیست امنیتی یا قالب گزارش تست نفوذ شما هنوز بر پایه‌ی ۲۰۲۱ نوشته شده، سه تغییر ساختاری مهم را از دست داده‌اید: SSRF دیگر دستهی مستقلی نیست، یک دستهی کامل برای زنجیره‌ی تأمین نرم‌افزار اضافه شده، و دستهی تازه‌ای برای مدیریت نادرست شرایط استثنایی ایجاد شده است. این راهنما هر ده دسته را با نام رسمی، مثال واقعی و راهکار رفع مرور میکند.
در یک نگاه
- نسخهی جاری OWASP Top 10:2025 است؛ نسخهی ۲۰۲۱ بایگانی شده و نباید مبنای گزارش جدید باشد.
- SSRF که در ۲۰۲۱ دستهی مستقل A10 بود، در ۲۰۲۵ داخل A01 کنترل دسترسی شکسته ادغام شده است.
- دو دستهی جدید: A03 نقص‌های زنجیره‌ی تأمین نرم‌افزار و A10 مدیریت نادرست شرایط استثنایی.
- پیکربندی نادرست از رتبه‌ی ۵ به رتبه‌ی ۲ صعود کرده — مهم‌ترین جابه‌جایی این نسخه.
- OWASP گزارش میکند در داده‌ی این نسخه، ۱۰۰٪ برنامه‌های آزموده‌شده نوعی نقص کنترل دسترسی داشته‌اند.
OWASP چیست و Top 10 چگونه ساخته میشود؟
بنیاد OWASP (Open Worldwide Application Security Project) یک نهاد غیرانتفاعی جهانی است که استانداردها، راهنماها و ابزارهای متن‌باز امنیت نرم‌افزار تولید میکند. شناخته‌شده‌ترین خروجی آن، فهرست Top 10 است: ردهبندی ده دستهی ریسک بحرانی در برنامه‌های وب که هر چند سال یکبار بر پایه‌ی داده‌ی واقعی بازنگری میشود و مبنای متدولوژی تست نفوذ در سراسر دنیاست.
نکته‌ای که اغلب اشتباه فهمیده میشود: Top 10 فهرستی از آسیب‌پذیری‌ها نیست، فهرستی از دسته‌های ریسک است. هر دسته ده‌ها CWE را زیر خود جمع میکند. مثلاً «تزریق» یک باگ نیست؛ چتری است روی SQL Injection، Command Injection، XSS و چند نوع دیگر.
روش ساخت نسخهی ۲۰۲۵ را خود OWASP «داده‌آگاه، اما نه کورکورانه داده‌محور» توصیف میکند: هشت دسته از دل داده رتبه‌بندی شده و دو دسته بر پایه‌ی نظرسنجی جامعه‌ی متخصصان بالا آمده‌اند. مقیاس داده قابل توجه است — حدود ۱۷۵٬۰۰۰ رکورد CVE نگاشت‌شده به CWE، و داده‌ی مشارکتی سازمان‌هایی که بیش از ۲٫۸ میلیون برنامه را آزموده‌اند. تعداد CWEهای یکتای نگاشت‌شده از ۲۴۱ مورد در ۲۰۲۱ به ۶۴۳ مورد رسیده است.
اگر پیمانکار امنیتی شما گزارشی تحویل می‌دهد که یافتهها را با برچسب «A10:2021 - SSRF» دسته‌بندی کرده، آن گزارش با تاکسونومی جاری هم‌راستا نیست. این موضوع در ممیزی‌های انطباق و در مقایسه‌ی گزارشهای چند پیمانکار، مشکل‌ساز میشود.
تغییرات نسخهی ۲۰۲۵ نسبت به ۲۰۲۱
سه تغییر ساختاری رخ داده است: یک ادغام و دو دستهی جدید. جدول زیر نگاشت کامل را نشان می‌دهد.
| نسخه ۲۰۲۱ | نسخه ۲۰۲۵ | تغییر |
|---|---|---|
| A01 — Broken Access Control | A01 — Broken Access Control | بدون تغییر در رتبه؛ SSRF را جذب کرد |
| A02 — Cryptographic Failures | A04 — Cryptographic Failures | دو پله نزول |
| A03 — Injection | A05 — Injection | دو پله نزول |
| A04 — Insecure Design | A06 — Insecure Design | دو پله نزول |
| A05 — Security Misconfiguration | A02 — Security Misconfiguration | سه پله صعود |
| A06 — Vulnerable and Outdated Components | A03 — Software Supply Chain Failures | تغییر نام و گسترش دامنه |
| A07 — Identification and Authentication Failures | A07 — Authentication Failures | تغییر نام؛ رتبه ثابت |
| A08 — Software and Data Integrity Failures | A08 — Software or Data Integrity Failures | رتبه ثابت |
| A09 — Security Logging and Monitoring Failures | A09 — Security Logging and Alerting Failures | تغییر نام |
| A10 — Server-Side Request Forgery (SSRF) | — | حذف بهعنوان دستهی مستقل؛ ادغام در A01 |
| — | A10 — Mishandling of Exceptional Conditions | دستهی کاملاً جدید |
ادغام SSRF تصمیم قابل بحثی بود اما منطق روشنی دارد: SSRF در عمل نوعی دور زدن مرز اعتماد و کنترل دسترسی است — مهاجم سرور را وادار میکند از طرف او به منبعی دسترسی پیدا کند که خودش اجازه‌اش را ندارد. صفحه‌ی رسمی A01:2025 صراحتاً می‌گوید CWE-918 (SSRF) و CWE-352 (CSRF) اکنون زیر این دسته قرار دارند.
در راهنمای تست OWASP یعنی WSTG، آزمون SSRF همچنان زیر بخش اعتبارسنجی ورودی (WSTG-INPV-19) قرار دارد، نه زیر مجوزدهی. این دو تاکسونومی هم‌راستا نیستند و نباید طوری ارائه شوند که انگار هستند.
A01:2025 — کنترل دسترسی شکسته (Broken Access Control)
نگه‌داشتن رتبه‌ی یک، و اکنون گسترده‌تر از همیشه: این دسته ۴۰ CWE را پوشش می‌دهد و پس از ادغام، شامل SSRF و CSRF هم میشود. آماری که OWASP منتشر کرده گویاست: ۱۰۰٪ برنامه‌های آزموده‌شده نوعی نقص کنترل دسترسی داشته‌اند.
ماهیت مشکل ساده است: برنامه بررسی نمیکند که این کاربرِ مشخص، حق انجام این عملیاتِ مشخص روی این رکوردِ مشخص را دارد یا نه.
سناریوهای واقعی
- دستکاری پارامتر: کاربر آدرس
/invoice?acct=1001را بهacct=1002تغییر می‌دهد و فاکتور شخص دیگری را می‌بیند. این همان IDOR است. - مرور اجباری: کاربر عادی مستقیماً مسیر
/admin/getAppInfoرا باز میکند و چون هیچ بررسی نقشی وجود ندارد، وارد میشود. - دور زدن کنترل سمت کلاینت: دکمه‌ی «حذف» در رابط کاربری برای کاربر عادی مخفی است، اما همان درخواست API با
curlبدون هیچ مانعی اجرا میشود.
«از UUID استفاده می‌کنیم پس IDOR نداریم.» شناسه‌های غیرقابل حدس فقط هزینه‌ی کشف را بالا می‌برند؛ آن‌ها هیچ بررسی مجوزی اضافه نمی‌کنند. UUID از مسیرهای دیگر نشت میکند: خروجی گزارش‌ها، هدر Referer، پاسخ سایر اندپوینت‌ها. کنترل دسترسی باید در سمت سرور و برای هر درخواست انجام شود.
راهکار رفع
- رد پیش‌فرض (Deny by default) برای هر چیزی جز منابع عمومی.
- اعمال کنترل فقط در سمت سرور — هرگز در جاوااسکریپت سمت کلاینت.
- یک سازوکار مرکزی و قابل استفاده‌ی مجدد برای کنترل دسترسی، نه بررسی پراکنده در هر کنترلر.
- اعمال مالکیت رکورد: کاربر فقط رکوردهای خودش را ببیند و تغییر دهد.
- ابطال نشست در سمت سرور پس از خروج؛ عمر کوتاه برای توکن‌های JWT.
- ثبت لاگ و هشدار برای شکست‌های کنترل دسترسی، و محدودسازی نرخ آن‌ها.
- غیرفعال‌سازی فهرست‌شدن دایرکتوری‌ها و حذف فایل‌های متادیتا از ریشه‌ی وب.
A02:2025 — پیکربندی نادرست (Security Misconfiguration)
بزرگ‌ترین جابه‌جایی این نسخه: صعود از رتبه‌ی ۵ به رتبه‌ی ۲. مثل A01، اینجا هم ۱۰۰٪ برنامه‌های آزموده‌شده متأثر بوده‌اند. OWASP این دسته را چنین تعریف میکند: «وقتی یک سامانه، برنامه یا سرویس ابری از منظر امنیتی نادرست پیکربندی میشود و آسیب‌پذیری ایجاد میکند.»
این رایج‌ترین یافته‌ی هر تست نفوذ وب است، و تقریباً همیشه ارزان‌ترین مورد برای رفع — چون نیاز به تغییر کد ندارد.
سناریوهای واقعی
- برنامه‌ی نمونه یا محیط دمو که روی سرور عملیاتی باقی مانده، با نام کاربری و رمز پیش‌فرض تغییرنیافته.
- فعال بودن فهرست‌شدن دایرکتوری؛ مهاجم فایل‌های کلاس را دانلود و دیکامپایل میکند و از دل آن‌ها نقص کنترل دسترسی پیدا میکند.
- پیام‌های خطای پرجزئیات و Stack Trace که نام و نسخهی دقیق کامپوننت‌ها را لو میدهند.
- باکت ذخیره‌سازی ابری که به‌صورت پیش‌فرض روی اشتراک عمومی است.
توجه کنید که XXE (یعنی CWE-611) در نسخهی ۲۰۲۵ زیر همین دسته قرار دارد، نه زیر تزریق.
راهکار رفع
- یک فرایند مقاوم‌سازی تکرارپذیر که در محیط توسعه، تست و عملیات یکسان اجرا شود.
- پلتفرم حداقلی: حذف قابلیت‌ها، کامپوننت‌ها، مستندات و نمونه‌های غیرضروری.
- راستی‌آزمایی خودکار پیکربندی در همه‌ی محیط‌ها؛ در حداقلی‌ترین حالت، بازبینی دستی سالانه.
- استفاده از هویت فدره و اعتبارنامه‌های کوتاه‌عمر به‌جای کلیدهای ثابت جاسازی‌شده.
- ارسال هدرهای امنیتی و غیرفعال‌سازی فهرست دایرکتوری.
- بازبینی دورهای مجوزهای فضای ذخیره‌سازی ابری.
A03:2025 — نقص‌های زنجیره‌ی تأمین نرم‌افزار (Software Supply Chain Failures)
این دسته جانشین «اجزای آسیب‌پذیر و قدیمی» در نسخهی ۲۰۲۱ است، اما صرفاً تغییر نام نیست — دامنه‌اش به‌مراتب گسترده‌تر شده. OWASP تصریح میکند که اکنون «همه‌ی نقص‌های زنجیره‌ی تأمین را پوشش می‌دهد، نه فقط مواردی که به آسیب‌پذیری شناخته‌شده مربوط‌اند.»
یعنی علاوه بر کتابخانه‌ی وصله‌نشده، این موارد هم داخل این دسته‌اند: ابزار ساخت آلوده، خط لوله‌ی CI/CD در معرض خطر، و کانال توزیع دستکاری‌شده.
حوادث واقعی که OWASP نام می‌برد
- SolarWinds (۲۰۱۹): به‌روزرسانی آلوده‌ی یک تأمین‌کننده‌ی مورد اعتماد، حدود ۱۸٬۰۰۰ سازمان را آلوده کرد.
- Bybit (۲۰۲۵): نرم‌افزار کیف پول مخرب که به‌صورت هدفمند علیه اهداف مشخص اجرا شد؛ ۱٫۵ میلیارد دلار سرقت.
- Shai-Hulud (۲۰۲۵): کرم خودتکثیر در npm؛ بیش از ۵۰۰ نسخهی بسته آلوده شد و با توکن‌های سرقتی npm خودش را گسترش داد.
- آسیب‌پذیری‌های کلاسیک اجزا: Log4Shell (CVE-2021-44228) و RCE در Struts 2 (CVE-2017-5638).
راهکار رفع
- مدیریت متمرکز SBOM (فهرست دارایی نرم‌افزاری) و موجودی‌برداری پیوسته.
- رصد NVD و اشتراک در هشدارهای آسیب‌پذیری.
- دریافت اجزا فقط از منابع رسمی، همراه با راستی‌آزمایی امضا.
- تفکیک وظایف در مخازن و خط لوله‌ی CI/CD.
- انتشار مرحله‌ای به‌جای استقرار هم‌زمان روی کل ناوگان.
- کنترل دسترسی سخت‌گیرانه و MFA روی کل زیرساخت توسعه.
A04:2025 — خطاهای رمزنگاری (Cryptographic Failures)
نبود رمزنگاری، رمزنگاری ضعیف، یا کلیدهای افشاشده. داده‌ی حساس — رمز عبور، شماره کارت، سوابق سلامت و اطلاعات هویتی — باید هم در حال انتقال و هم در حال سکون محافظت شود. OWASP صراحتاً به تعهدات GDPR و PCI DSS ارجاع می‌دهد.
سناریوهای واقعی
- مهاجم ترافیک رمزنگاری‌نشده را شنود میکند یا HTTPS را به HTTP تنزل می‌دهد، کوکی نشست را می‌دزدد و نشست احراز هویت‌شده را می‌رباید.
- پایگاه‌داده‌ی رمزهای عبور با هش بدون نمک از طریق یک نقص آپلود فایل افشا میشود و با جدول رنگین‌کمانی و شتاب‌دهی GPU شکسته میشود.
راهکار رفع
- طبقهبندی داده و الزام رمزنگاری در حال سکون و انتقال (TLS نسخهی ۱٫۲ به بالا).
- نگهداری کلیدها در HSM یا سرویس مدیریت کلید ابری.
- هش رمز عبور با نمک، ترجیحاً با Argon2.
- کنار گذاشتن الگوریتم‌های منسوخ: MD5 و SHA-1.
- مدیریت درست IV در رمزنگاری متقارن.
- OWASP توصیه میکند سازمان‌ها برای رمزنگاری پساکوانتومی تا سال ۲۰۳۰ آماده شوند.
A05:2025 — تزریق (Injection)
تعریف رسمی: «نقصی که اجازه می‌دهد ورودی نامعتبر به یک مفسر ارسال شود و مفسر بخشی از آن ورودی را بهعنوان دستور اجرا کند.» این دسته ۳۷ CWE را پوشش می‌دهد و شامل SQL، NoSQL، دستور سیستم‌عامل، ORM، LDAP، Expression Language — و XSS — است.
دو CWE سنگین‌وزن اینجا هستند: CWE-89 (تزریق SQL) با بیش از ۱۴٬۰۰۰ CVE و CWE-79 (XSS) با بیش از ۳۰٬۰۰۰ CVE.
سناریوهای واقعی
- تزریق SQL: پارامتر
idبا مقدار' OR '1'='1احراز هویت را دور می‌زند یا کل رکوردها را بیرون می‌کشد. - تزریق ORM/HQL: رشته‌ی
' OR custID IS NOT NULL OR custID='در یک کوئری Hibernate فیلترگذاری را خنثی میکند. - تزریق دستور: افزودن
; cat /etc/passwdبه پارامتری که به شل منتقل میشود.
«کوئری پارامتری، تزریق SQL را غیرممکن میکند.» این جمله ناقص است. کوئری پارامتری شناسه‌ها (نام جدول، نام ستون، عبارت ORDER BY) را پوشش نمی‌دهد. همچنین در برابر رویه‌های ذخیره‌شده‌ای که داخل خودشان رشته می‌چسبانند، تزریق مرتبه‌دوم، و راه‌های فرار ORM بی‌اثر است. برای شناسه‌ها باید از فهرست سفید استفاده کرد.
راهکار رفع
- APIهای پارامتری، Prepared Statement یا ORM — هر چیزی که داده را از دستور جدا کند.
- اعتبارسنجی ورودی با فهرست سفید، در سمت سرور.
- کدگذاری متناسب با مفسر، جایی که پارامتری‌سازی ممکن نیست.
- ادغام SAST، DAST و IAST در خط لوله‌ی CI/CD.
A06:2025 — طراحی ناامن (Insecure Design)
ضعفی که در معماری است، نه در کد. جمله‌ی کلیدی خود OWASP بهترین توضیح است: «یک طراحی امن می‌تواند نقص پیاده‌سازی داشته باشد که به آسیب‌پذیری منجر شود. اما یک طراحی ناامن را هیچ پیاده‌سازی بی‌نقصی نمی‌تواند اصلاح کند.»
سناریوهای واقعی
- بازیابی رمز عبور از طریق «سؤال امنیتی» — روشی که با راهنمای NIST در تضاد است، چون پاسخ‌ها برای افراد متعددی قابل دانستن‌اند.
- سامانه‌ی رزرو سینما: مهاجم صدها صندلی را در سالن‌های مختلف رزرو میکند تا زیر آستانه‌ی پرداخت بیعانه باقی بماند — سوءاستفاده‌ی منطق کسب‌وکار.
- فروشگاهی بدون محافظت در برابر ربات؛ کالای محدود در چند ثانیه توسط ربات‌های خرید تمام میشود.
این دسته دقیقاً همان بخشی است که هیچ اسکنر خودکاری پیدا نمیکند. باگ‌های منطق کسب‌وکار فقط با آزمون دستی و درک فرایند کشف می‌شوند — و همین، تفاوت بنیادی اسکن آسیب‌پذیری با تست نفوذ واقعی است.
راهکار رفع
- ادغام مدل‌سازی تهدید در فرایند طراحی.
- کتابخانه‌ای از الگوهای طراحی امن و «مسیر آماده» برای تیم توسعه.
- تست واحد و یکپارچگی که سناریوهای سوءاستفاده را هم پوشش دهد، نه فقط سناریوهای کاربرد.
- جداسازی لایه‌ها و مستأجرها در سطح طراحی.
- بررسی معقول‌بودن داده در هر لایه از برنامه.
A07:2025 — خطاهای احراز هویت (Authentication Failures)
نام این دسته در ۲۰۲۵ کوتاه شده: از «Identification and Authentication Failures» به «Authentication Failures». رتبه‌اش تغییری نکرده و همچنان ۷ است. موضوع، دور زدن احراز هویت است: اعتبارسنجی معیوب اعتبارنامه، سازوکار حفاظتی ناکافی، و مدیریت ناامن نشست.
سناریوهای واقعی
- Credential Stuffing با جهش الگو: مهاجم فهرست رمزهای فاش‌شده را تغییر می‌دهد — مثلاً
Winter2025را بهWinter2026. - احراز هویت تک‌عاملی همراه با قواعد پیچیدگی رمز، که در عمل کاربر را به بازاستفاده‌ی رمز سوق می‌دهد.
- انقضای نادرست نشست؛ به‌ویژه در محیط‌های SSO که خروج یکپارچه (SLO) ندارند.
راهکار رفع
- پیاده‌سازی احراز هویت چندعاملی.
- پشتیبانی از مدیر رمز عبور؛ اجبار به تعویض دورهای رمز را حذف کنید.
- هرگز اعتبارنامه‌ی پیش‌فرض ارسال نکنید.
- بررسی رمزهای جدید در برابر مجموعه‌های فاش‌شده.
- هم‌راستایی سیاست رمز با NIST SP 800-63B.
- محدودسازی نرخ و تأخیر در ورودهای ناموفق.
- مدیر نشست سمت سرور با شناسهی تصادفی و پرآنتروپی در کوکی امن.
- برای JWT: اعتبارسنجی ادعاهای
audوissالزامی است.
A08:2025 — نقص یکپارچگی نرم‌افزار یا داده
ناتوانی در حفظ مرزهای اعتماد و راستی‌آزمایی یکپارچگی کد و داده. توجه کنید که نام رسمی در ۲۰۲۵ از «Software and Data» به «Software or Data» تغییر کرده است.
سناریوهای واقعی
- در معرض خطر قرار گرفتن DNS یا CDN یک تأمین‌کننده، که به مهاجم اجازه می‌دهد کوکی‌های احراز هویت را بخواند.
- روتر خانگی یا میان‌افزاری با به‌روزرسانی بدون امضا — تزریق به‌روزرسانی مخرب.
- توسعه‌دهنده‌ای که بسته‌ی بدون امضا از منبع غیررسمی نصب میکند.
- Deserialization داده‌ی سریال‌شده‌ی تحت کنترل مهاجم در جاوا و رسیدن به RCE.
این دو با هم همپوشانی دارند اما یکی نیستند: A03 درباره‌ی فرایند زنجیره‌ی تأمین است (چگونه نرم‌افزار ساخته، توزیع و به‌روز میشود)، و A08 درباره‌ی راستی‌آزمایی یکپارچگی و مرزهای اعتماد. آن‌ها را مکمل هم توصیف کنید، نه یکسان.
راهکار رفع
- راستی‌آزمایی امضای دیجیتال روی نرم‌افزار و به‌روزرسانی‌ها.
- استفاده از مخازن مورد اعتماد یا آینه‌ی داخلی بررسی‌شده.
- بازبینی کد برای تغییرات پیکربندی خط لوله.
- تفکیک وظایف و کنترل دسترسی در CI/CD.
- راستی‌آزمایی یکپارچگی داده‌ی سریال‌شده با چک‌سام یا امضا.
A09:2025 — نقص ثبت رخداد و هشداردهی امنیتی
تغییر نام از «Monitoring» به «Alerting» عمدی و معنادار است: جابه‌جایی تمرکز از جمع‌آوری منفعل لاگ به تشخیص و پاسخ عملیاتی. جمله‌ی OWASP: «بدون ثبت و پایش، حملات و رخنه‌ها قابل تشخیص نیستند؛ و بدون هشداردهی، پاسخ سریع و مؤثر در جریان یک رخداد امنیتی بسیار دشوار است.»
سناریوهای واقعی که OWASP ذکر میکند
- یک ارائه‌دهنده‌ی طرح سلامت کودکان: رخنه‌ای که ۳٫۵ میلیون کودک را متأثر کرد و از سال ۲۰۱۳ به‌دلیل نبود لاگ و پایش کشف نشده بود — سرانجام توسط یک طرف بیرونی گزارش شد.
- یک شرکت هواپیمایی اروپایی: رخنه‌ی مشمول GDPR شامل بیش از ۴۰۰٬۰۰۰ رکورد پرداخت مشتری، با جریمه‌ی ۲۰ میلیون پوند.
راهکار رفع
- ثبت همه‌ی رخدادهای مرتبط با امنیت، با زمینه‌ی کافی برای شناسایی حساب مشکوک.
- کدگذاری خروجی لاگ برای جلوگیری از تزریق به لاگ (CWE-117).
- مسیر ممیزی فقط-افزودنی با حفاظت یکپارچگی.
- تعریف سناریوهای پایش همراه با کتابچه‌ی پاسخ به رخداد متناظر.
- استقرار Honeytoken برای تشخیص دسترسی غیرمجاز.
A10:2025 — مدیریت نادرست شرایط استثنایی
دستهی کاملاً جدید. تعریف OWASP: «برنامه‌ها در پیشگیری، تشخیص و پاسخ به موقعیت‌های غیرعادی و غیرقابل پیش‌بینی ناکام می‌مانند، که به کرش، رفتار غیرمنتظره و گاهی آسیب‌پذیری منجر میشود.»
این دسته ضعف‌هایی را جمع کرده که پیش‌تر زیر برچسب کلی «کیفیت پایین کد» پراکنده بودند. ۲۴ CWE زیر آن قرار دارد، از جمله CWE-209 (پیام خطای حاوی اطلاعات حساس) و CWE-636 (شکست ناامن یا «Failing Open»).
سناریوهای واقعی
- منع سرویس از راه تخلیه‌ی منابع: برنامه استثنای آپلود را می‌گیرد اما منبع را هرگز آزاد نمیکند؛ در دسترس‌پذیری به‌مرور افت میکند.
- افشای اطلاعات: مدیریت نادرست خطای پایگاه‌داده، ساختار اسکیما را لو می‌دهد و مهاجم از همان برای ساخت تزریق SQL استفاده میکند.
- خرابی وضعیت تراکنش: مهاجم عمداً یک تراکنش مالی چندمرحله‌ای را قطع میکند و از بازگشت ناقص (Rollback ناتمام) برای تخلیه‌ی حساب سوءاستفاده میکند.
راهکار رفع
- مدیریت خطا در همان نقطه‌ای که رخ می‌دهد، به‌علاوه‌ی یک مدیریت خطای مرکزی.
- اعتبارسنجی سخت‌گیرانه‌ی ورودی.
- ثبت لاگ جامع با سطح جزئیات مناسب.
- یک Global Exception Handler بهعنوان تور ایمنی.
- محدودیت منابع، محدودسازی نرخ و سهمیه‌بندی.
- اصل کلیدی: Fail closed، نه fail open.
چطور از این فهرست در عمل استفاده کنیم؟
Top 10 نقطه‌ی شروع است، نه پایان کار. خود OWASP هشدار می‌دهد که این فهرست یک استاندارد انطباق نیست و پوشش کامل نمی‌دهد. مسیر عملی:
- نگاشت دارایی‌ها: فهرستی از همه‌ی برنامه‌ها، APIها و زیردامنه‌های خود تهیه کنید. چیزی که نمی‌دانید وجود دارد را نمی‌توانید ایمن کنید.
- ارزیابی دسته‌به‌دسته: برای هر برنامه، ده دسته را مرور کنید. از A01 و A02 شروع کنید — بر پایه‌ی داده‌ی ۲۰۲۵ این دو در ۱۰۰٪ برنامه‌ها یافت شده‌اند.
- اولویت‌بندی با CVSS: هر یافته را امتیازدهی کنید و مشخص کنید از کدام نسخه (۴٫۰ یا ۳٫۱) استفاده کرده‌اید.
- پوشش کامل با WSTG: برای آزمون فنی، Top 10 کافی نیست. WSTG با ۹۷ آزمون نام‌گذاری‌شده، چک‌لیست پوششی واقعی است.
- آزمون دستی برای منطق کسب‌وکار: دستهی A06 (طراحی ناامن) و بخش بزرگی از A01 با هیچ ابزار خودکاری کشف نمی‌شوند.
«گواهی OWASP»، «انطباق با OWASP» و «OWASP Certified» وجود خارجی ندارند. OWASP نهاد صدور گواهی نیست. عبارت درست این است: «ردهبندی ریسک بر پایه‌ی OWASP Top 10:2025 و پوشش آزمون بر پایه‌ی WSTG v4.2».
اگر می‌خواهید بدانید سامانه‌ی شما در برابر کدام‌یک از این ده دسته آسیب‌پذیر است، تست نفوذ وب پی‌هانتر دقیقاً همین ارزیابی را با گزارش قابل اقدام و راهکار رفع ارائه می‌دهد.
پرسش‌های متداول
آخرین نسخهی OWASP Top 10 کدام است؟
نسخهی ۲۰۲۵، که هشتمین نسخهی این فهرست است و روی owasp.org/Top10/2025/ منتشر شده. نسخهی ۲۰۲۱ اکنون بایگانی محسوب میشود و نباید مبنای گزارشهای جدید تست نفوذ باشد.
چرا SSRF از فهرست ۲۰۲۵ حذف شده است؟
حذف نشده، ادغام شده. SSRF در نسخهی ۲۰۲۱ دستهی مستقل A10 بود و اکنون زیر A01 کنترل دسترسی شکسته قرار گرفته، چون در ماهیت نوعی دور زدن مرز اعتماد است. CWE-918 همچنان شناسهی رسمی آن است و اهمیت فنیاش ذرهای کم نشده.
آیا OWASP Top 10 یک استاندارد انطباق است؟
خیر. یک سند آگاهیبخشی و ردهبندی ریسک است. هیچ گواهی «OWASP Certified» وجود ندارد و هیچ نهادی انطباق با آن را ممیزی نمیکند. استانداردهایی مثل PCI DSS به آن ارجاع میدهند، اما خودِ Top 10 چارچوب انطباق نیست. برای پوشش آزمون فنی باید از WSTG استفاده کرد.
تفاوت OWASP Top 10 با WSTG چیست؟
Top 10 یک تاکسونومی ریسک است — ده دسته برای طبقهبندی یافتهها. WSTG یک متدولوژی آزمون است — ۹۷ آزمون مشخص و شناسهدار که مشخص میکند چه چیزی را چگونه تست کنید. در یک گزارش حرفهای، پوشش آزمون با WSTG بیان میشود و شدت یافته با Top 10 و CVSS.
آیا XSS هنوز در OWASP Top 10 هست؟
بله، اما نه بهعنوان دستهی مستقل. XSS (یعنی CWE-79) از نسخهی ۲۰۲۱ زیر دستهی تزریق قرار دارد که در ۲۰۲۵ شمارهی A05 گرفته است. با بیش از ۳۰٬۰۰۰ CVE، همچنان پرحجمترین CWE این دسته است.
هر چند وقت یکبار باید سامانه را در برابر OWASP Top 10 ارزیابی کرد؟
قاعدهی عملی: حداقل سالی یکبار، و همچنین پس از هر تغییر معماری مهم، افزودن قابلیت حساس (پرداخت، احراز هویت، آپلود فایل)، یا مهاجرت زیرساخت. برای برنامههایی با چرخهی انتشار سریع، ترکیب اسکن خودکار پیوسته با تست نفوذ دستی دورهای منطقیتر است.
منابع
علیرضا کیا
متخصص تست نفوذ وب و اندروید با سابقه‌ی مدیریت تیم نفوذ در داتین. مهندسی معکوس اپ‌ها و کشف ذخیره‌سازی ناامن، تخصص اوست.