امنیت وب اپلیکیشن با خرید یک فایروال یا نصب گواهی SSL شروع و تمام نمی‌شود. آسیب‌پذیری‌هایی که در عمل به نشت داده و از دست رفتن کنترل سامانه منجر می‌شوند، تقریباً همیشه در منطق و کد خود برنامه هستند — جایی که هیچ محصول محیطی به آن دسترسی ندارد. این راهنما دو لایه را کنار هم می‌گذارد: نخست ده دستهی ریسک OWASP Top 10:2025 با نام و ترتیب رسمی، و سپس لایهی فرایندی که مانع بازتولید همان نقص‌ها در انتشار بعدی می‌شود.
در یک نگاه
- مرجع جاری رده‌بندی ریسک، OWASP Top 10:2025 است — هشتمین نسخه؛ نسخهی ۲۰۲۱ بایگانی شده است.
- دو دستهی مهم جابه‌جا شده‌اند: پیکربندی نادرست به رتبهی ۲ صعود کرده و زنجیرهی تأمین نرمافزار بهعنوان A03 وارد فهرست شده است.
- کنترل دسترسی همچنان رتبهی یک است؛ OWASP گزارش میکند در داده‌ی این نسخه ۱۰۰٪ برنامه‌های آزموده‌شده نوعی نقص کنترل دسترسی داشته‌اند.
- ابزار خودکار — SAST و DAST — نقصهای تزریق و پیکربندی را خوب پیدا میکند و نقصهای کنترل دسترسی و منطق کسبوکار را عملاً پیدا نمیکند.
- بدون مدل‌سازی تهدید، بازبینی کد و مدیریت وابستگی، هر تست نفوذ فقط یک عکس لحظه‌ای است؛ سه ماه بعد وضعیت از نو خراب می‌شود.
امنیت وب اپلیکیشن چیست و مرز آن کجاست؟
امنیت وب اپلیکیشن (Web Application Security) به مجموعه‌ی کنترل‌ها، فرایندها و آزمون‌هایی گفته می‌شود که از لایهی برنامه محافظت میکند: کد سمت سرور، منطق کسبوکار، APIها، مدیریت نشست، کنترل دسترسی، و رفتار سمت کلاینت. این حوزه با امنیت شبکه و امنیت زیرساخت هم‌مرز است اما یکی نیست.
تفاوت را با یک مثال ساده می‌توان دید. فرض کنید سامانه‌ی شما پشت یک فایروال قرار دارد، فقط پورت ۴۴۳ باز است، گواهی TLS معتبر دارد و سرورش کاملاً وصله‌شده است. اگر اندپوینت GET /api/invoices/1042 بررسی نکند که کاربر جاری مالک فاکتور ۱۰۴۲ است، هر کاربر ثبت‌نام‌شده می‌تواند فاکتور همه را بخواند. از دید شبکه، این ترافیک کاملاً مجاز و رمزنگاری‌شده است. هیچ پورتی باز نشده و هیچ بدافزاری اجرا نشده. این یک نقص لایهی برنامه است و فقط با درک منطق برنامه قابل کشف است.
به همین دلیل سه پرسش محور کار است: هر کاربر چه چیزی را می‌تواند ببیند و تغییر دهد (کنترل دسترسی)؟ ورودی کاربر در کدام مفسرها مینشیند (تزریق)؟ برنامه در شرایط غیرمنتظره چه رفتاری دارد (مدیریت خطا و منطق)؟
اگر مفاهیم پایه مثل تفاوت احراز هویت و مجوزدهی یا مرز اعتماد کلاینت و سرور برای شما تازه است، پیشنهاد می‌کنیم پیش از ادامه، مقاله‌ی امنیت وب چیست را بخوانید؛ این مقاله از آن نقطه به بعد را می‌سازد.
چارچوب مرجع: OWASP Top 10:2025
برای اینکه بحث امنیت برنامه از سلیقه‌ی شخصی خارج شود، به یک تاکسونومی مشترک نیاز دارید. مرجع پذیرفته‌شده‌ی جهانی، فهرست OWASP Top 10 است. نسخهی جاری OWASP Top 10:2025 است که هشتمین نسخهی این فهرست به‌شمار می‌رود و بر پایه‌ی حدود ۱۷۵٬۰۰۰ رکورد CVE نگاشت‌شده به CWE، به‌علاوه‌ی داده‌ی سازمان‌هایی که بیش از ۲٫۸ میلیون برنامه را آزموده‌اند، ساخته شده است.
این فهرست، فهرست آسیبپذیری نیست؛ فهرست دسته‌های ریسک است و مجموعاً ۲۴۸ عدد CWE بین این ده دسته توزیع شده.
| شناسه | نام رسمی | معادل فارسی | تعداد CWE |
|---|---|---|---|
| A01:2025 | Broken Access Control | کنترل دسترسی شکسته (شامل SSRF و CSRF) | ۴۰ |
| A02:2025 | Security Misconfiguration | پیکربندی نادرست امنیتی | ۱۶ |
| A03:2025 | Software Supply Chain Failures | نقصهای زنجیرهی تأمین نرمافزار | ۶ |
| A04:2025 | Cryptographic Failures | خطاهای رمزنگاری | ۳۲ |
| A05:2025 | Injection | تزریق (شامل XSS) | ۳۷ |
| A06:2025 | Insecure Design | طراحی ناامن | ۳۹ |
| A07:2025 | Authentication Failures | خطاهای احراز هویت | ۳۶ |
| A08:2025 | Software or Data Integrity Failures | نقص یکپارچگی نرمافزار یا داده | ۱۴ |
| A09:2025 | Security Logging and Alerting Failures | نقص ثبت رخداد و هشداردهی امنیتی | ۵ |
| A10:2025 | Mishandling of Exceptional Conditions | مدیریت نادرست شرایط استثنایی | ۲۴ |
«ما با OWASP Top 10 منطبق هستیم.» چنین چیزی وجود ندارد. OWASP نهاد صدور گواهی نیست و Top 10 استاندارد انطباق نیست — یک سند آگاهی‌بخشی و رده‌بندی ریسک است. خود OWASP هم تصریح میکند که این فهرست پوشش کامل نمی‌دهد. ادعای درست این است: «رده‌بندی ریسک بر پایه‌ی OWASP Top 10:2025 و پوشش آزمون بر پایه‌ی WSTG». تفکیک این دو در مقاله‌ی تفصیلی OWASP Top 10 توضیح داده شده است.
A01 تا A03: کنترل دسترسی، پیکربندی و زنجیرهی تأمین
A01:2025 — کنترل دسترسی شکسته
رتبهی یک، و پس از نسخهی ۲۰۲۵ گسترده‌تر از قبل: SSRF (که در ۲۰۲۱ دستهی مستقل A10 بود) و CSRF اکنون زیر همین دسته قرار دارند. آماری که OWASP منتشر کرده گویاست: ۱۰۰٪ برنامه‌های آزموده‌شده نوعی نقص کنترل دسترسی داشته‌اند.
سه الگوی تکرارشونده:
- دستکاری پارامتر: تغییر
?acct=1001به?acct=1002و دیدن داده‌ی کاربر دیگر — همان IDOR. - مرور اجباری: کاربر عادی مستقیماً مسیر
/admin/getAppInfoرا باز میکند و چون بررسی نقش وجود ندارد، وارد می‌شود. - کنترل فقط در سمت کلاینت: دکمه در رابط کاربری مخفی است اما همان درخواست با
curlبی‌مانع اجرا می‌شود.
راهکار: رد پیش‌فرض برای هر منبع غیرعمومی، اعمال کنترل صرفاً در سمت سرور، یک سازوکار مرکزی و قابل استفاده‌ی مجدد به‌جای بررسی پراکنده در هر کنترلر، و اعمال مالکیت رکورد در لایهی دسترسی به داده. جزئیات فنی در دانشنامه‌ی کنترل دسترسی شکسته و SSRF آمده است.
A02:2025 — پیکربندی نادرست امنیتی
بزرگ‌ترین جابه‌جایی این نسخه: صعود از رتبهی ۵ به رتبهی ۲. این هم مثل A01 در ۱۰۰٪ برنامه‌های آزموده‌شده دیده شده است. نمونه‌های شاخصی که OWASP ذکر میکند: برنامهی نمونه یا دمو که روی سرور عملیاتی جا مانده با اعتبارنامه‌ی پیش‌فرض، فعال بودن فهرست‌شدن دایرکتوری، پیام‌های خطای پرجزئیات و Stack Trace که نام و نسخهی کامپوننت‌ها را لو می‌دهند، و باکت ذخیره‌سازی ابری با اشتراک پیش‌فرض عمومی.
توجه کنید که XXE (یعنی CWE-611) در نسخهی ۲۰۲۵ زیر این دسته قرار دارد، نه زیر تزریق. راهکار محوری، یک فرایند مقاوم‌سازی تکرارپذیر است که در توسعه، تست و عملیات یکسان اجرا شود، به‌علاوه‌ی راستی‌آزمایی خودکار پیکربندی.
A03:2025 — نقصهای زنجیرهی تأمین نرمافزار
جانشین «اجزای آسیب‌پذیر و قدیمی» در نسخهی ۲۰۲۱، اما با دامنه‌ای بسیار وسیع‌تر: OWASP تصریح میکند این دسته اکنون «همهی نقصهای زنجیرهی تأمین را پوشش می‌دهد، نه فقط مواردی که به آسیبپذیری شناخته‌شده مربوط‌اند». یعنی ابزار ساخت آلوده، خط لوله‌ی CI/CD در معرض خطر، و کانال توزیع دستکاری‌شده هم اینجا می‌نشینند.
حوادثی که OWASP به نام ذکر میکند: SolarWinds (۲۰۱۹) با آلوده‌سازی حدود ۱۸٬۰۰۰ سازمان از طریق به‌روزرسانی یک تأمین‌کننده‌ی مورد اعتماد؛ Bybit (۲۰۲۵) با سرقت ۱٫۵ میلیارد دلار از طریق نرمافزار کیف پول مخرب؛ و Shai-Hulud (۲۰۲۵)، کرم خودتکثیر در npm که بیش از ۵۰۰ نسخهی بسته را آلوده کرد. کنار این‌ها، آسیب‌پذیری‌های کلاسیک اجزا مثل Log4Shell (CVE-2021-44228) هم در همین دسته‌اند.
A04 تا A06: رمزنگاری، تزریق و طراحی
A04:2025 — خطاهای رمزنگاری
نبود رمزنگاری، پیاده‌سازی ضعیف، یا کلید افشاشده. OWASP صراحتاً به تعهدات GDPR و PCI DSS ارجاع می‌دهد. دو سناریوی مرجع: شنود ترافیک رمزنگاری‌نشده یا تنزل HTTPS به HTTP برای سرقت کوکی نشست؛ و افشای پایگاه‌داده‌ی رمزهای عبور با هش بدون نمک که با جدول رنگین‌کمانی و شتاب‌دهی GPU شکسته می‌شود.
خط پایه: TLS نسخهی ۱٫۲ به بالا، نگهداری کلید در HSM یا سرویس مدیریت کلید، هش رمز با نمک و ترجیحاً Argon2، کنار گذاشتن MD5 و SHA-1، و — توصیه‌ی صریح OWASP — آماده شدن برای رمزنگاری پساکوانتومی تا سال ۲۰۳۰.
A05:2025 — تزریق
تعریف رسمی: نقصی که اجازه می‌دهد ورودی نامعتبر به یک مفسر برسد و مفسر بخشی از آن ورودی را بهعنوان دستور اجرا کند. این دسته SQL، NoSQL، دستور سیستم‌عامل، ORM، LDAP، Expression Language و XSS را پوشش می‌دهد. دو CWE سنگین‌وزن اینجا هستند: CWE-89 (تزریق SQL) با بیش از ۱۴٬۰۰۰ CVE و CWE-79 (XSS) با بیش از ۳۰٬۰۰۰ CVE. در فهرست CWE Top 25 سال ۲۰۲۵ هم همین دو مورد رتبهی یک و دو را دارند.
«کوئری پارامتری تزریق SQL را غیرممکن میکند.» ناقص است. پارامتری‌سازی شناسه‌ها را پوشش نمی‌دهد — نام جدول، نام ستون و عبارت ORDER BY در SQL استاندارد قابل bind نیستند و باید با فهرست سفید سمت سرور نگاشت شوند. همچنین در برابر رویه‌های ذخیره‌شده‌ای که داخل خودشان رشته می‌چسبانند، تزریق مرتبه‌دوم، راه‌های فرار ORM (مثل raw())، و NoSQL بی‌اثر است.
A06:2025 — طراحی ناامن
ضعفی که در معماری است، نه در کد. جمله‌ی خود OWASP بهترین توضیح است: «یک طراحی امن می‌تواند نقص پیاده‌سازی داشته باشد که به آسیبپذیری منجر شود؛ اما یک طراحی ناامن را هیچ پیاده‌سازی بی‌نقصی نمی‌تواند اصلاح کند.»
سناریوهای مرجع OWASP آموزنده‌اند: بازیابی رمز از طریق «سؤال امنیتی» که با راهنمای NIST در تضاد است؛ سامانه‌ی رزرو سینما که مهاجم با رزرو پراکنده‌ی صدها صندلی زیر آستانه‌ی پرداخت بیعانه می‌ماند؛ و فروشگاهی بدون محافظت در برابر ربات که موجودی محدودش در چند ثانیه تمام می‌شود. این دسته دقیقاً جایی است که هیچ اسکنر خودکاری کاری از پیش نمی‌برد.
A07 تا A10: احراز هویت، یکپارچگی، لاگ و شرایط استثنایی
A07:2025 — خطاهای احراز هویت
نام این دسته در ۲۰۲۵ از «Identification and Authentication Failures» به Authentication Failures کوتاه شده و رتبه‌اش همان ۷ مانده است. سناریوهای مرجع: Credential Stuffing با جهش الگو (تبدیل Winter2025 به Winter2026 در فهرست‌های فاش‌شده)، احراز هویت تک‌عاملی همراه با قواعد پیچیدگی که کاربر را به بازاستفاده‌ی رمز سوق می‌دهد، و انقضای نادرست نشست — بهویژه در محیط‌های SSO بدون خروج یکپارچه (SLO).
راهکارها: احراز هویت چندعاملی، پشتیبانی از مدیر رمز و حذف اجبار به تعویض دورهای، بررسی رمزهای جدید در برابر مجموعه‌های فاش‌شده، هم‌راستایی با NIST SP 800-63B، محدودسازی نرخ ورود، و مدیر نشست سمت سرور با شناسه‌ی پرآنتروپی در کوکی امن. اگر از JWT استفاده می‌کنید، اعتبارسنجی ادعاهای aud و iss الزامی است.
A08:2025 — نقص یکپارچگی نرمافزار یا داده
ناتوانی در حفظ مرزهای اعتماد و راستی‌آزمایی یکپارچگی کد و داده: افزونه و کتابخانه از منابع تأییدنشده، CI/CD ناامن، به‌روزرسانی خودکار بدون امضا، و Deserialization ناامن. نام رسمی هم یک تغییر یک‌کلمه‌ای داشته: «Software and Data» در ۲۰۲۱ به «Software or Data» در ۲۰۲۵.
این دو همپوشانی دارند اما یکی نیستند. A03 درباره‌ی فرایند زنجیرهی تأمین است — چگونه نرمافزار ساخته، توزیع و به‌روز می‌شود. A08 درباره‌ی راستی‌آزمایی یکپارچگی و مرزهای اعتماد است. آنها را مکمل هم در نظر بگیرید، نه معادل.
A09:2025 — نقص ثبت رخداد و هشداردهی امنیتی
تغییر نام از «Monitoring» به Alerting عمدی است: جابه‌جایی تمرکز از جمع‌آوری منفعل لاگ به تشخیص و پاسخ عملیاتی. یکی از سناریوهای مرجع OWASP، رخنه‌ای در یک ارائه‌دهنده‌ی طرح سلامت کودکان است که ۳٫۵ میلیون کودک را متأثر کرد و از سال ۲۰۱۳ به‌دلیل نبود لاگ و پایش کشف نشده بود — سرانجام یک طرف بیرونی آن را گزارش کرد.
راهکارها: ثبت رخدادهای امنیتی با زمینه‌ی کافی، کدگذاری خروجی لاگ برای جلوگیری از تزریق به لاگ (CWE-117)، مسیر ممیزی فقط-افزودنی با حفاظت یکپارچگی، و تعریف سناریوهای پایش همراه با کتابچه‌ی پاسخ به رخداد.
A10:2025 — مدیریت نادرست شرایط استثنایی
دستهی کاملاً جدید. تعریف OWASP: برنامه‌ها در پیشگیری، تشخیص و پاسخ به موقعیت‌های غیرعادی ناکام می‌مانند، که به کرش، رفتار غیرمنتظره و گاهی آسیبپذیری منجر می‌شود. سه سناریوی مرجع: منع سرویس از راه تخلیه‌ی منابع (استثنای آپلود گرفته می‌شود اما منبع آزاد نمی‌شود)، افشای ساختار اسکیما از طریق خطای مدیریت‌نشده‌ی پایگاه‌داده که سپس برای ساخت تزریق استفاده می‌شود، و قطع عمدی یک تراکنش مالی چندمرحله‌ای و سوءاستفاده از Rollback ناتمام.
اصل کلیدی این دسته در یک جمله: Fail closed، نه fail open. CWE-636 که «شکست ناامن» است، دقیقاً همین را توصیف میکند.
لایهی دوم: چرخهی توسعهی امن
ده دستهی بالا فهرست چه چیزی است. اما اگر فقط پس از انتشار به‌دنبال آنها بگردید، هر نسخهی جدید همان اشتباهات را بازتولید میکند. لایهی دوم امنیت وب اپلیکیشن، جای دادن کنترل‌ها داخل چرخهی توسعه است.
مدل‌سازی تهدید در مرحله‌ی طراحی
مدل‌سازی تهدید ارزانترین کنترل امنیتی موجود است، چون روی وایت‌بورد انجام می‌شود و هنوز کدی نوشته نشده. چهار پرسش کافی است: چه می‌سازیم؟ چه چیزی می‌تواند خراب شود؟ در برابرش چه می‌کنیم؟ آیا کارمان خوب بود؟
برای هر قابلیت جدید — به‌خصوص پرداخت، احراز هویت و آپلود فایل — دو چیز را روی کاغذ مشخص کنید: مرزهای اعتماد، و سناریوهای سوءاستفاده. توصیه‌ی OWASP در A06 هم همین است: تست‌ها باید سناریوهای سوءاستفاده را پوشش دهند، نه فقط سناریوهای کاربرد.
بازبینی امن کد
بازبینی امن کد جای بازبینی معمول کد را نمی‌گیرد؛ لایه‌ای است روی آن با پرسش‌های مشخص. در عمل، بازبینی هدفمند بهتر از بازبینی سطرسطر کل مخزن جواب می‌دهد. روی این نقاط تمرکز کنید:
- هر جا که کوئری، دستور سیستم‌عامل یا قالب از رشته ساخته می‌شود.
- هر جا که شناسه‌ای از ورودی کاربر به کوئری می‌رسد — سراغ شرط مالکیت بروید.
- هر جا که فایل آپلودشده ذخیره یا سرو می‌شود، یا داده‌ی سریال‌شده و XML از بیرون خوانده می‌شود.
- میان‌افزار احراز هویت و مجوزدهی: کدام مسیرها از آن مستثنا شده‌اند؟
الگوهای امن به‌جای دستور امنیتی
راهکاری که در سازمان‌ها جواب می‌دهد، ساختن «مسیر آماده» است: اگر لایهی داده فقط از طریق ریپازیتوری‌ای قابل استفاده باشد که خودش شرط مالکیت را اعمال میکند، توسعهدهنده برای نوشتن کد ناامن باید تلاش اضافی کند. آموزش هم بخشی از همین لایه است — دوره‌ی سازمانی توسعهی امن برای همین نقطه طراحی شده.
SAST و DAST در CI/CD: چه می‌بینند و چه نمی‌بینند
ابزار خودکار در خط لوله جای خود را دارد، به‌شرط اینکه انتظار درستی از آن داشته باشید. جدول زیر تقسیم کار واقعی را نشان می‌دهد.
| لایه | چه چیزی خوب پیدا میکند | چه چیزی را عملاً پیدا نمیکند | جای مناسب در خط لوله |
|---|---|---|---|
| SAST (تحلیل ایستا) | الگوهای تزریق، رمز و کلید هاردکد، سوءاستفاده از APIهای رمزنگاری، الگوهای ناامن شناخته‌شده | کنترل دسترسی، منطق کسبوکار، هر چیزی که به وضعیت زمان اجرا وابسته است | Pull Request؛ فقط قواعد پرسیگنال را blocking کنید |
| DAST (تحلیل پویا) | پیکربندی نادرست، هدرهای غایب، XSS بازتابی، تزریق قابل مشاهده، فایل و مسیر افشاشده | IDOR و مجوزدهی، منطق چندمرحله‌ای، شرایط مسابقه، بخش عمدهی DOM XSS | محیط Staging شبیه به عملیاتی، نه روی هر کامیت |
| SCA / وابستگی | CVEهای شناخته‌شده در اجزا، بسته‌های رهاشده و بدون نگه‌دارنده | وابستگی مخرب تازه‌منتشرشده که هنوز CVE ندارد | هر بیلد، به‌علاوه‌ی اسکن زمان‌بندی‌شده‌ی مخزن |
| تست دستی | کنترل دسترسی، منطق کسبوکار، زنجیرهی چند نقص، شرایط مسابقه | پوشش وسیع و تکرار روزانه — گران است | پیش از انتشار عمده و به‌صورت دورهای |
«اسکنر ما هر هفته اجرا می‌شود، پس امنیت برنامه پوشش داده شده است.» اسکنر نمی‌تواند بداند کاربر شماره‌ی ۵ مجاز است رکورد شماره‌ی ۷ را ببیند یا نه. تحلیل ایستا هم نقصهای کنترل دسترسی و منطق را تقریباً هیچ پیدا نمیکند. این دقیقاً همان جایی است که پرتأثیرترین یافته‌های وب زندگی می‌کنند و تنها راه کشفشان، آزمون دستی با درک فرایند کسبوکار است. تفاوت اسکن و تست نفوذ همین است.
مدیریت وابستگی و SBOM
با رفتن زنجیرهی تأمین به رتبهی A03، مدیریت وابستگی از یک کار نگهداری به یک کنترل امنیتی درجه‌یک تبدیل شده است. توصیه‌های OWASP در این دسته را می‌توان به یک چک‌لیست عملیاتی تبدیل کرد:
- SBOM متمرکز: فهرست دارایی نرم‌افزاری هر سرویس، تولیدشده در زمان بیلد. اگر ندانید چه کتابخانه‌ای با چه نسخه‌ای در عملیات اجرا می‌شود، روز انتشار یک CVE بحرانی نمی‌توانید در چند دقیقه پاسخ دهید.
- دریافت اجزا فقط از منابع رسمی با راستی‌آزمایی امضا، ترجیحاً از طریق مخزن آینه‌ی داخلی؛ و قفل کردن نسخه‌ها با بازبینی تغییرات lockfile در Pull Request — یک ارتقای مشکوک باید همان‌قدر جلب توجه کند که تغییر در کد احراز هویت.
- تفکیک وظایف و MFA روی کل زیرساخت توسعه — مخزن کد، رجیستری بسته و CI/CD — به‌علاوه‌ی انتشار مرحله‌ای به‌جای استقرار هم‌زمان روی کل ناوگان.
برای چرخهی کامل شناسایی، اولویت‌بندی و رفع، مدیریت آسیبپذیری را ببینید.
از ارزیابی به برنامه: ترتیب کارها
ترتیب اجرایی پیشنهادی: نخست موجودی دارایی — شامل محیط‌های Staging فراموش‌شده با داده‌ی واقعی که یکی از رایج‌ترین یافته‌های جدی است؛ سپس پاک کردن A02 که ارزانترین دسته برای رفع است چون تغییر کد لازم ندارد؛ بعد MFA روی هر پنل مدیریت و هر حساب توسعهدهنده؛ سپس راه‌اندازی SBOM و اسکن وابستگی و یک فرایند مشخص واکنش به CVE؛ مدل‌سازی تهدید برای قابلیت‌های حساس پیش از نوشتن کد؛ و در پایان تست نفوذ دستی برای A01 و A06 که با ابزار پیدا نمی‌شوند. فهرست تفصیلی و اولویت‌دار همین اقدامات در افزایش امنیت سایت آمده است.
برای سنجش وضعیت فعلی، راهنمای بررسی امنیت سایت یک خودارزیابی گام‌به‌گام می‌دهد و چک‌لیست امنیتی فهرست عملیاتی همان مراحل است. و یک اصل در پایان: گزارشی که آزمون مجدد ندارد نیمه‌کاره است — ساختار مطلوب در گزارش تست نفوذ آمده. اگر می‌خواهید بدانید سامانه‌ی شما در برابر کدام‌یک از این ده دسته آسیب‌پذیر است، تست نفوذ وب پی‌هانتر همین ارزیابی را با پوشش WSTG، امتیازدهی CVSS و آزمون مجدد رفع انجام می‌دهد.
پرسش‌های متداول
امنیت وب اپلیکیشن با امنیت شبکه چه تفاوتی دارد؟
امنیت شبکه از مسیرها و پورتها محافظت میکند؛ امنیت وب اپلیکیشن از منطق برنامه. یک درخواست HTTPS کاملاً مجاز که فاکتور کاربر دیگری را برمیگرداند، از دید فایروال و IDS بیعیب است اما یک نقص بحرانی لایهی برنامه است. این دو مکملاند و هیچکدام جانشین دیگری نیست.
آخرین نسخهی OWASP Top 10 کدام است و چه تغییری کرده؟
نسخهی ۲۰۲۵، هشتمین نسخهی این فهرست. سه تغییر ساختاری دارد: SSRF از دستهی مستقل A10 به داخل A01 (کنترل دسترسی) منتقل شده، دستهی جدید A03 نقصهای زنجیرهی تأمین نرمافزار اضافه شده، و دستهی جدید A10 مدیریت نادرست شرایط استثنایی ایجاد شده است. همچنین پیکربندی نادرست از رتبهی ۵ به ۲ صعود کرده.
آیا نصب فایروال وب اپلیکیشن (WAF) جای امنسازی کد را میگیرد؟
خیر. WAF یک کنترل جبرانی و «خریدار زمان» است — مثلاً وصلهی مجازی تا زمان انتشار اصلاح واقعی. اما ساختاراً نسبت به کنترل دسترسی شکسته (A01)، منطق کسبوکار، شرایط مسابقه و بخش عمدهی DOM XSS نابیناست، و قابل دور زدن است — بهویژه با پیدا کردن IP اصلی سرور پشت آن. WAF هرگز نباید بهعنوان «راهکار رفع» یک آسیبپذیری کد در گزارش نوشته شود. توضیح کامل WAF را ببینید.
برای شروع امنسازی یک وب اپلیکیشن از کجا باید شروع کنم؟
از موجودی دارایی و سپس دستهی A02 (پیکربندی نادرست)، چون ارزانترین و پرتکرارترین است. بعد MFA روی همهی پنلهای مدیریت و حسابهای توسعهدهنده، سپس مدیریت وابستگی و SBOM. کنترل دسترسی و منطق کسبوکار را برای آزمون دستی نگه دارید، چون هیچ ابزاری آنها را پیدا نمیکند.
SAST و DAST چه تفاوتی دارند و کدام را اول راه بیندازم؟
SAST کد را بدون اجرا تحلیل میکند و در Pull Request مینشیند؛ DAST برنامهی در حال اجرا را از بیرون آزمون میکند و جای مناسبش محیط Staging است. اگر تیم توسعهی فعال دارید، SAST را اول راه بیندازید چون بازخورد را به لحظهی نوشتن کد نزدیک میکند — اما فقط قواعد پرسیگنال را blocking کنید تا خط لوله از اعتبار نیفتد.
چند وقت یکبار باید وب اپلیکیشن را تست نفوذ کرد؟
قاعدهی عملی: حداقل سالی یکبار، و علاوه بر آن پس از هر تغییر معماری مهم، افزودن قابلیت حساس (پرداخت، احراز هویت، آپلود فایل) یا مهاجرت زیرساخت. برای برنامههایی با چرخهی انتشار سریع، ترکیب اسکن پیوستهی خودکار با تست نفوذ دستی دورهای منطقیتر از یک تست سنگین سالانه است.
منابع
علیرضا کیا
متخصص تست نفوذ وب و اندروید با سابقه‌ی مدیریت تیم نفوذ در داتین. مهندسی معکوس اپ‌ها و کشف ذخیره‌سازی ناامن، تخصص اوست.