بررسی امنیت سایت را بدون تیم امنیتی هم می‌توان تا حد قابل توجهی انجام داد — اگر بدانید دنبال چه هستید و محدودیت‌های کارتان را بپذیرید. این راهنما یک ارزیابی خودارزیاب را مرحله‌به‌مرحله جلو می‌برد، هر مرحله را به دسته‌های متناظر در راهنمای تست امنیت وب OWASP (یعنی WSTG) نگاشت میکند، و در پایان صریح می‌گوید کدام خانواده‌ی آسیب‌پذیری‌ها را هیچ خودارزیابی‌ای پیدا نمی‌کند — چون دانستن سقف کار، بخشی از حرفهای بودن آن است.
در یک نگاه
- خودارزیابی میتواند پیکربندی نادرست، اجزای قدیمی، فایلهای افشاشده و ضعف TLS و هدرها را پیدا کند — یعنی بخش بزرگی از یافتههای ارزان.
- خودارزیابی نمیتواند کنترل دسترسی شکسته، نقص منطق کسبوکار و شرایط مسابقه را پیدا کند. اینها گران‌ترین آسیب‌پذیری‌ها هستند و به آزمون دستی نیاز دارند.
- مرجع پوشش آزمون، WSTG است: حدود ۹۷ آزمون در ۱۲ دسته. نسخهی پایدار جاری v4.2 است.
- همه‌ی آزمون‌ها را فقط روی دارایی‌های خودتان انجام دهید و اگر روی هاست اشتراکی هستید، پیش از اسکن به میزبان اطلاع دهید.
- خروجی این کار یک فهرست اولویت‌دار است، نه یک نمرهی امنیتی. «۹۰ از ۱۰۰» هیچ معنایی ندارد.
بررسی امنیت سایت یعنی چه، و نقشه‌ی کار کجاست؟
«بررسی امنیت سایت» در عمل سه کار متفاوت است که اغلب با هم اشتباه می‌شوند:
- اسکن خودکار: ابزار به‌دنبال الگوهای شناخته‌شده می‌گردد. سریع، ارزان، پوشش سطحی.
- خودارزیابی ساختاریافته: شما با یک چکلیست، داراییها و پیکربندی خود را مرور می‌کنید. همان کاری که این مقاله آموزش می‌دهد.
- تست نفوذ: آزمونگر با فهم کسبوکار شما، عمداً به‌دنبال دور زدن منطق و کنترل دسترسی می‌رود.
برای اینکه خودارزیابی به یک فهرست دلبخواهی تبدیل نشود، به یک نقشه نیاز دارید. نقشه‌ی مرجع جهانی، OWASP Web Security Testing Guide است. نسخهی پایدار جاری آن v4.2 است که در ۳ دسامبر ۲۰۲۰ منتشر شد؛ پروژه یک نسخهی وب «stable» را هم به‌صورت پیوسته نگه‌داری میکند و نسخهی ۵٫۰ در حال توسعه است. WSTG حدود ۹۷ آزمون سطح‌بالا را در ۱۲ دسته سازمان می‌دهد و هر آزمون شناسه‌ی خودش را دارد؛ همین است که آن را از یک فهرست توصیه به یک ابزار پوشش‌سنجی تبدیل میکند.
پیش از شروع، یک تذکر لازم: این آزمون‌ها را فقط روی دارایی‌هایی انجام دهید که مالک آن‌ها هستید یا مجوز کتبی دارید. اگر روی هاست اشتراکی هستید، اسکن‌های پرحجم میتواند شبیه حمله به‌نظر برسد و به تعلیق حساب منجر شود؛ از پیش به میزبان اطلاع دهید. و برای هر تغییر پیکربندی، ابتدا پشتیبان بگیرید.
گام ۱ — نگاشت دارایی و جمع‌آوری اطلاعات
معادل WSTG: دسته‌ی WSTG-INFO (جمع‌آوری اطلاعات، ۱۰ آزمون). قاعده‌ی ساده: چیزی که نمی‌دانید وجود دارد را نمی‌توانید ایمن کنید.
- فهرست کامل زیردامنهها. فقط
wwwنه — همه‌چیز:staging،test،old،api،panel،mail،backup. زیردامنه‌ی فراموش‌شده با نسخهی قدیمی برنامه یکی از پرتکرارترین یافتههای جدی است. ابزارهای شمارش غیرفعال زیردامنه مثل subfinder این کار را در چند ثانیه انجام میدهند. - فهرست سرویس‌هایی که واقعاً از بیرون قابل دسترسی‌اند. اغلب چیزی بیشتر از تصور تیم است: پنل مدیریت، phpMyAdmin، اندپوینت API، صفحه‌ی مستندات، سرویسهای روی پورت‌های غیراستاندارد مثل ۸۰۸۰ و ۸۴۴۳. Nmap با
-sVتفاوت «چیزی که فکر می‌کنید باز است» و «چیزی که واقعاً باز است» را نشان می‌دهد. - اثرانگشت پلتفرم. نسخهی وب‌سرور، زبان اجرایی، CMS و فریم‌ورک. اگر نسخه در هدر پاسخ یا صفحه‌ی خطا اعلام می‌شود، آن هم خودش یک یافته‌ی کوچک است.
- فایلهای متا:
robots.txtوsitemap.xmlرا بخوانید. مسیرهایی که درrobots.txt«منع» شده‌اند، عملاً فهرست مسیرهای حساس شما هستند و اولین چیزی است که هر مهاجم می‌خواند. - نشت در محتوای صفحه. در سورس صفحه و فایلهای جاوااسکریپت بسته‌بندی‌شده به‌دنبال اینها بگردید: کامنت‌های توسعه‌دهنده، آدرس اندپوینت‌های داخلی، کلید API، و فایلهای
.mapجامانده که کل ساختار کد اصلی را بازسازی می‌کنند.
روش کار پیشنهادی برای همین یک گام: خروجی هر ابزار را در یک صفحه‌گسترده جمع کنید، ستون «مالک» و «آیا باید از بیرون قابل دسترسی باشد؟» اضافه کنید. تجربه نشان می‌دهد پاسخ «نه» برای بخش قابل توجهی از ردیف‌ها همین‌جا مشخص می‌شود — و بستن آن‌ها ارزان‌ترین کاهش ریسک ممکن است. اصول کامل این مرحله در شناسایی توضیح داده شده است.
گام ۲ — پیکربندی، فایلهای افشاشده و پنل‌ها
معادل WSTG: دسته‌ی WSTG-CONF (مدیریت پیکربندی و استقرار، ۱۱ آزمون) که شامل فایلهای قدیمی و پشتیبان، رابط‌های مدیریتی، متدهای HTTP، HSTS، مجوز فایل‌ها، تصاحب زیردامنه و فضای ذخیره‌سازی ابری است. این پرمحصول‌ترین بخش خودارزیابی است، چون پیکربندی نادرست در OWASP Top 10:2025 رتبه‌ی دوم را دارد و در ۱۰۰٪ برنامه‌های آزموده‌شده دیده شده است.
مسیرهایی که باید دستی امتحان کنید
اینها را در مرورگر یا با curl باز کنید و کد وضعیت پاسخ را ببینید. هر پاسخ ۲۰۰ یک یافته است:
/.git/config
/.env
/backup.zip /db.sql /site.tar.gz
/phpmyadmin/ /adminer.php
/wp-config.php.bak
/server-status- فهرست‌شدن دایرکتوری: چند مسیر بدون فایل پیشفرض را باز کنید — مثلاً پوشه‌ی آپلود. اگر فهرست فایل‌ها را دیدید، آن را در وب‌سرور خاموش کنید.
- تصاحب زیردامنه: برای هر رکورد DNS از نوع CNAME که به سرویس ابری اشاره میکند، بررسی کنید آن سرویس همچنان فعال است. رکورد جامانده به سرویسی که حذف شده، امکان تصاحب زیردامنه را می‌دهد.
- متدهای HTTP: بررسی کنید متدهای غیرلازم مثل
TRACEوPUTغیرفعال باشند. - فضای ذخیره‌سازی ابری: اگر از باکت استفاده می‌کنید، مجوز دسترسی عمومی را بازبینی کنید. پیشفرض عمومی یکی از سناریوهای رسمی OWASP در همین دسته است.
ابزارهایی که این گام را سریع می‌کنند
یک اسکنر مسیر مثل ffuf یا feroxbuster با فهرست‌واژه‌های SecLists میتواند فایلهای افشاشده را در چند دقیقه پیدا کند. Nuclei هم برای همین دسته عالی است: یک تطبیق‌دهنده‌ی امضای قالب‌محور که پنلهای افشاشده، فایلهای حساس، پیکربندیهای نادرست و اعتبارنامه‌های پیشفرض را خوب پیدا میکند. اما توجه کنید که Nuclei اسکنر مسائل شناخته‌شده است، نه ابزار کشف آسیبپذیری تازه — و کیفیت نتیجه‌اش به کیفیت قالب‌ها بستگی دارد.
گام ۳ — احراز هویت، نشست و کنترل دسترسی سطحی
معادل WSTG: WSTG-IDNT (مدیریت هویت، ۵ آزمون)، WSTG-ATHN (احراز هویت، ۱۰ آزمون) و WSTG-SESS (مدیریت نشست، ۹ آزمون). بخشی از اینها را می‌توانید خودتان بررسی کنید:
- اعتبارنامهی پیشفرض. برای هر سرویس و پنلی که در گام یک پیدا کردید، بررسی کنید حساب پیشفرض تغییر کرده باشد. برنامه‌ی نمونه یا دموی جامانده با رمز پیشفرض، سناریوی شماره‌ی یک OWASP در دسته‌ی پیکربندی نادرست است.
- قفل شدن و محدودسازی نرخ. ده ورود ناموفق متوالی را امتحان کنید. اگر هیچ تأخیر، CAPTCHA یا قفلی رخ نداد، پنل شما در برابر Credential Stuffing باز است.
- شمارش حساب. پیام «این ایمیل ثبت نشده است» در برابر «رمز اشتباه است» به مهاجم می‌گوید کدام ایمیل‌ها کاربر شما هستند. پیام باید یکسان باشد. همین را در فرم بازیابی رمز هم بررسی کنید.
- بازیابی رمز عبور. بررسی کنید لینک بازیابی یک‌بارمصرف، دارای انقضای کوتاه و مقید به همان حساب باشد. سؤال امنیتی را کنار بگذارید — OWASP آن را نمونه‌ی صریح طراحی ناامن می‌داند چون پاسخ‌ها برای افراد متعددی قابل دانستن‌اند.
- صفتهای کوکی. در ابزار توسعه‌دهنده‌ی مرورگر، برگه‌ی Application، کوکی نشست را ببینید: باید
SecureوHttpOnlyداشته باشد وSameSiteصریحاً تعیین‌شده باشد. توکن احراز هویت درlocalStorageیک یافته است، چون با هر XSS قابل خواندن می‌شود. - خروج و انقضا. پس از خروج، همان درخواست قبلی را بازپخش کنید. اگر همچنان کار کرد، نشست در سمت سرور ابطال نشده است.
- MFA. بررسی کنید روی همه‌ی مسیرهای ورود فعال باشد، نه فقط یکی. اگر یک نقطه‌ی ورود جانبی — مثلاً API یا اپلیکیشن قدیمی — احراز هویت ضعیف‌تری دارد، عملاً MFA دور زده می‌شود. این دقیقاً آزمون WSTG-ATHN-10 است.
یک آزمون کنترل دسترسی سطحی که خودتان هم می‌توانید انجام دهید: دو حساب با سطح دسترسی مختلف بسازید، با حساب کم‌دسترسی وارد شوید، و آدرس یک صفحه‌ی مدیریتی را مستقیماً باز کنید. اگر بدون خطا باز شد، یک نقص جدی دارید. توجه کنید این فقط نوک این خانواده است؛ در بخش سقف خودارزیابی توضیح می‌دهیم چرا.
گام ۴ — TLS، هدرها و مدیریت خطا
معادل WSTG: WSTG-CRYP (رمزنگاری ضعیف، ۴ آزمون) و WSTG-ERRH (مدیریت خطا، ۲ آزمون). این گام کاملاً قابل خودارزیابی است و ابزارش هم رایگان است.
TLS
با testssl.sh یا sslyze یا اسکریپت ssl-enum-ciphers در Nmap بررسی کنید:
- TLS 1.3 فعال باشد و TLS 1.0 و 1.1 خاموش — این دو رسماً منسوخ شده‌اند و مذاکره‌شان نباید مجاز باشد.
- اگر TLS 1.2 را برای سازگاری نگه داشته‌اید، فقط مجموعه‌رمزهای ECDHE با AEAD باقی بمانند. استانداردهای جدید، مجموعه‌رمزهای RSA ثابت و FFDHE را در TLS 1.2 کنار گذاشته‌اند.
- زنجیره‌ی گواهی کامل باشد و تاریخ انقضا پایش شود. علت‌های رایج خطای گواهی در این مقاله آمده است.
- هدر
Strict-Transport-Securityباmax-ageطولانی ارسال شود و هدایت HTTP به HTTPS کامل باشد.
هدرهای امنیتی
با curl -I https://example.com یا برگه‌ی Network در ابزار توسعه‌دهنده، وجود اینها را بررسی کنید: Strict-Transport-Security، Content-Security-Policy، X-Content-Type-Options: nosniff، Referrer-Policy، و frame-ancestors در CSP. اگر CSP دارید، آن را در ارزیاب CSP گوگل بررسی کنید — و اگر 'unsafe-inline' در script-src دارد، در برابر XSS عملاً بی‌اثر است. سیاست بر پایه‌ی فهرست دامنه هم تقریباً همیشه دور زده می‌شود؛ شکل درست، nonce با strict-dynamic است.
مدیریت خطا
چند ورودی نامعتبر بدهید: حرف در فیلدی که عدد می‌خواهد، رشته‌ی خیلی بلند، آرایه در جای رشته، و نوع محتوای اشتباه در درخواست API. پاسخ باید یک خطای عمومی باشد. اگر Stack Trace، نام جدول پایگاهداده، مسیر کامل فایل روی سرور یا نسخهی کامپوننت را دیدید، یافته‌ی معتبری ثبت کنید — این هم دسته‌ی A02 است و هم به دسته‌ی جدید A10:2025 (مدیریت نادرست شرایط استثنایی) مربوط می‌شود. یکی از سناریوهای رسمی OWASP همین است: مهاجم از ساختار اسکیمای افشاشده در پیام خطا برای ساختن تزریق استفاده میکند.
چکلیست بررسی امنیت سایت
خروجی گام‌های بالا را در این قالب جمع کنید. ستون «قابل خودارزیابی» صادقانه پر شده است.
| مورد بررسی | دسته‌ی WSTG | قابل خودارزیابی؟ | اولویت |
|---|---|---|---|
| فهرست کامل زیردامنهها و سرویسهای در معرض اینترنت | WSTG-INFO | بله | بالا |
فایل پشتیبان، .env و پوشه‌ی .git در دسترس | WSTG-CONF | بله | بالا |
| فهرست‌شدن دایرکتوری و پنلهای مدیریتی افشاشده | WSTG-CONF | بله | بالا |
| اعتبارنامهی پیشفرض روی سرویس‌ها و پنل‌ها | WSTG-ATHN | بله | بالا |
| MFA روی همه‌ی مسیرهای ورود مدیریتی | WSTG-ATHN | بله | بالا |
| محدودسازی نرخ ورود و رفتار قفل حساب | WSTG-ATHN | بله | متوسط |
| صفتهای کوکی نشست و ابطال پس از خروج | WSTG-SESS | بله | بالا |
| نسخهی TLS و مجموعه‌رمزها، HSTS | WSTG-CRYP | بله | متوسط |
| هدرهای امنیتی و کیفیت سیاست CSP | WSTG-CLNT | بله | متوسط |
| افشای اطلاعات در پیام خطا و Stack Trace | WSTG-ERRH | بله | متوسط |
| نسخهی اجزا و آسیب‌پذیری‌های شناختهشدهی آن‌ها | WSTG-INFO / CONF | تا حدی | بالا |
| تصاحب زیردامنه و رکوردهای DNS جامانده | WSTG-CONF | تا حدی | متوسط |
| تزریق SQL، دستور و قالب | WSTG-INPV | خیر | بحرانی |
| IDOR و دور زدن ساختار مجوزدهی | WSTG-ATHZ | خیر | بحرانی |
| ارتقای سطح دسترسی | WSTG-ATHZ | خیر | بحرانی |
| نقص منطق کسبوکار و دور زدن گردش کار | WSTG-BUSL | خیر | بحرانی |
| شرایط مسابقه و دور زدن سقف‌ها | WSTG-BUSL | خیر | بالا |
| آپلود فایل مخرب و اجرای کد از آن مسیر | WSTG-BUSL | خیر | بحرانی |
| DOM XSS و آسیب‌پذیری‌های سمت کلاینت | WSTG-CLNT | خیر | بالا |
نسخهی قابل چاپ و عملیاتی همین موارد در چکلیست امنیتی پی‌هانتر در دسترس است.
سقف خودارزیابی: چه چیزی را نمی‌توانید پیدا کنید
این بخش مهم‌ترین بخش مقاله است. اگر گام‌های بالا را انجام دهید و همه‌چیز «تمیز» باشد، نتیجه‌گیری درست این نیست که سایت شما امن است. نتیجهی درست این است که آسیب‌پذیری‌های ارزان و خودکارپیدا را حذف کرده‌اید. سه خانواده باقی می‌ماند که نه با چکلیست و نه با اسکنر پیدا می‌شوند:
۱. کنترل دسترسی شکسته
رتبه‌ی یک OWASP Top 10:2025 و — بر پایه‌ی دادهی همین نسخه — موجود در ۱۰۰٪ برنامه‌های آزموده‌شده. دلیل ساختاری اینکه ابزار آن را پیدا نمی‌کند: ابزار نمی‌داند چه چیزی باید مجاز باشد. وقتی اسکنر درخواستی می‌فرستد و پاسخ ۲۰۰ می‌گیرد، نمیتواند تشخیص دهد این پاسخ درست است یا یک نشت داده. روش واقعی کشف، احراز هویت با دو کاربر در سطوح مختلف، ثبت مجموعه‌ی کامل درخواست‌های هر کدام، و بازپخش هر درخواست با نشست دیگری است — کاری که به فهم قواعد کسبوکار نیاز دارد. جزئیات در کنترل دسترسی شکسته و IDOR.
۲. نقص منطق کسبوکار
دسته‌ی WSTG-BUSL با ۹ آزمون، و در OWASP معادل A06:2025 (طراحی ناامن). نمونه‌های OWASP گویاست: سامانه‌ی رزرو سینما که مهاجم با رزرو پراکنده‌ی صدها صندلی زیر آستانه‌ی پرداخت بیعانه می‌ماند، یا فروشگاهی که ربات‌ها موجودی محدودش را در چند ثانیه تمام می‌کنند. جمله‌ی کلیدی خود OWASP: «یک طراحی ناامن را هیچ پیاده‌سازی بی‌نقصی نمیتواند اصلاح کند.» هیچ ابزاری نمی‌داند گردش کار درست در کسبوکار شما چیست.
۳. شرایط مسابقه
شرایط مسابقه از دید هر فیلتری نامرئی است، چون هر درخواست به‌تنهایی کاملاً مجاز است؛ مشکل در هم‌زمانی است. کد تخفیف یک‌بارمصرف که ده بار اعمال می‌شود، برداشت بیش از موجودی، دور زدن شمارنده‌ی تلاش MFA. و برخلاف تصور قدیمی، اینها روی اینترنت هم کاملاً عملی‌اند: تکنیک «حمله‌ی تک‌بسته» با استفاده از HTTP/2 نوفه‌ی شبکه را عملاً حذف میکند.
«اسکنر آنلاین گفت سایت من مشکلی ندارد.» ابزارهای رایگان و اسکنرهای آنلاین، مسائل شناخته‌شده و پیکربندی نادرست را پیدا می‌کنند و در همان محدوده مفیدند. اما نسبت به مجوزدهی و منطق نابینا هستند، و «هیچ یافته‌ای» در خروجی آن‌ها اطلاعاتی درباره‌ی امنیت واقعی برنامه‌ی شما نمی‌دهد. یک عدد یا نمرهی امنیتی از این ابزارها هم معنای فنی ندارد. تفاوت اسکن و تست نفوذ دقیقاً همین است — توضیح کامل در انواع تست نفوذ.
ارزیابی حرفهای چه چیزی اضافه میکند؟
یک تست نفوذ حرفهای چهار چیز اضافه میکند که هیچ‌کدام با ابزار قابل جانشینی نیست:
- پوشش آزمون قابل اثبات. یافته‌ها و آزمون‌های انجام‌شده با شناسه‌ی WSTG ارجاع می‌شوند، بنابراین می‌دانید چه چیزی آزموده شده و مشکلی نداشته — که به‌اندازه‌ی فهرست یافته‌ها مهم است.
- آزمون احراز هویت‌شده با چند نقش. بخش عمده‌ی آسیب‌پذیری‌های پرتأثیر فقط پس از ورود و در تعامل بین نقش‌ها دیده می‌شوند. این نیازمند حسابهای آزمون و درک نقش‌های شماست.
- زنجیرهسازی نقصها. یک تغییر مسیر باز به‌تنهایی کم‌اهمیت است؛ همان در کنار جریان OAuth به سرقت کد مجوز و در کنار یک واکشنده‌ی سمت سرور به دور زدن فیلتر SSRF منجر می‌شود. اثبات اثر واقعی، کار آزمونگر است نه ابزار.
- اولویت‌بندی و آزمون مجدد. شدت با CVSS امتیازدهی می‌شود، راهکار رفع به زبان تیم توسعه نوشته می‌شود، و پس از اعمال اصلاح، آزمون مجدد انجام می‌شود. گزارشی که آزمون مجدد ندارد نیمه‌کاره است — ساختار مطلوب در گزارش تست نفوذ توضیح داده شده.
ترتیب منطقی این است: خودارزیابی این مقاله را انجام دهید، یافتههای ارزان را رفع کنید، گام‌های عملی افزایش امنیت سایت را ببندید، و بعد ارزیابی حرفهای را سفارش دهید. این ترتیب باعث می‌شود بودجه‌ی تست صرف کشف موارد بدیهی نشود. برای فهم ساختار قیمت‌گذاری، هزینه‌ی امنیت سایت و هزینه‌ی تست نفوذ را ببینید؛ و برای تعریف دامنه‌ی دقیق کار، صفحه‌ی تست نفوذ وب.
پرسش‌های متداول
چطور امنیت سایتم را خودم بررسی کنم؟
با پنج گام: فهرست کامل زیردامنهها و سرویسهای در معرض اینترنت، بررسی فایلهای افشاشده مثل پشتیبان و .git و پنلهای مدیریتی، بررسی اعتبارنامهی پیشفرض و MFA و صفتهای کوکی، بررسی نسخهی TLS و هدرهای امنیتی، و آزمون رفتار برنامه در برابر ورودی نامعتبر. چکلیست کامل در همین مقاله آمده است.
آیا سایتهای آنلاین بررسی امنیت سایت قابل اعتمادند؟
در محدودهی خودشان بله: هدرهای امنیتی، نسخهی TLS، برخی پیکربندیهای نادرست و نسخههای شناختهشدهی آسیبپذیر را درست تشخیص میدهند. اما نتیجهی «مشکلی یافت نشد» نباید بهعنوان تأیید امنیت خوانده شود، چون این ابزارها نسبت به کنترل دسترسی، منطق کسبوکار و شرایط مسابقه نابینا هستند. نمرهی امنیتی این ابزارها هم معنای فنی مشخصی ندارد.
بررسی امنیت سایت با تست نفوذ چه تفاوتی دارد؟
بررسی یا خودارزیابی، مرور ساختاریافتهی پیکربندی و داراییها با چکلیست است و بیشتر یافتههای ارزان را پیدا میکند. تست نفوذ، آزمون فعال با چند نقش کاربری، تلاش برای دور زدن مجوزدهی و منطق، و زنجیرهسازی نقصها برای اثبات اثر واقعی است. دومی چیزهایی پیدا میکند که اولی ساختاراً نمیتواند.
چک کردن امنیت سایت به سایتم آسیب میزند؟
بررسیهای سبک — خواندن هدرها، بررسی مسیرها، آزمون TLS — بیخطرند. اما اسکن پرحجم مسیر یا اسکنر آسیبپذیری میتواند بار زیادی ایجاد کند، دادهی زائد در پایگاهداده بنویسد، یا روی هاست اشتراکی شبیه حمله دیده شود. پیش از هر اسکن جدی پشتیبان بگیرید، از ساعت کمترافیک استفاده کنید و به میزبان اطلاع دهید.
هر چند وقت یکبار امنیت سایت را بررسی کنم؟
بررسی سبک — نسخهی اجزا، پشتیبان، هدرها، حسابهای فعال — ماهانه. خودارزیابی کامل با چکلیست، فصلی یا پس از هر تغییر عمده. ارزیابی حرفهای، حداقل سالی یکبار و علاوه بر آن پس از تغییر معماری یا افزودن قابلیت حساس مثل پرداخت یا آپلود فایل.
WSTG چیست و چرا در بررسی امنیت به آن ارجاع می‌دهید؟
WSTG یا Web Security Testing Guide، راهنمای تست امنیت وب OWASP است: حدود ۹۷ آزمون شناسه‌دار در ۱۲ دسته. نسخهی پایدار جاری v4.2 است (منتشرشده در دسامبر ۲۰۲۰) و نسخهی ۵٫۰ در حال توسعه است. ارزش آن این است که پوشش آزمون را قابل اندازه‌گیری میکند: می‌توانید بگویید کدام آزمون‌ها انجام شده‌اند و کدام نه.
منابع
علیرضا کیا
متخصص تست نفوذ وب و اندروید با سابقه‌ی مدیریت تیم نفوذ در داتین. مهندسی معکوس اپ‌ها و کشف ذخیره‌سازی ناامن، تخصص اوست.