این صفحه کاتالوگ عملی باگهای امنیتی سایت است؛ نه فهرستی از نام‌های ترسناک، بلکه کلاس‌هایی که در برنامه‌های وب ایرانی واقعاً پیدا می‌شوند — با نشانه‌ای که هر کلاس در ترافیک و کد از خود به‌جا می‌گذارد، روشی که با آن کشف میشود، اثر واقعی‌اش روی کسبوکار، و راهکار رفع. سازمان‌دهی بر پایه‌ی OWASP Top 10:2025 است و هر کلاس به شناسهی CWE خود نگاشت شده. اگر تازه با مفاهیم آشنا می‌شوید، ابتدا باگ چیست را بخوانید؛ این صفحه سطح فنی‌تری دارد و برای توسعه‌دهنده و مدیر فنی نوشته شده است.
در یک نگاه
- دستهی A01 کنترل دسترسی شکسته بیشترین حجم یافته‌های واقعی را می‌سازد و OWASP گزارش میکند در دادهی ۲۰۲۵ ۱۰۰٪ برنامه‌های آزموده‌شده نوعی نقص کنترل دسترسی داشته‌اند.
- پیکربندی نادرست در نسخه‌ی ۲۰۲۵ از رتبه‌ی ۵ به رتبه‌ی ۲ رسید — و ارزان‌ترین دسته برای رفع است، چون تغییر کد لازم ندارد.
- SSRF دیگر دستهی مستقل نیست؛ در ۲۰۲۵ به‌همراه CSRF داخل A01 ادغام شده است.
- هیچ اسکنری کنترل دسترسی، منطق کسبوکار و شرایط مسابقه را قابل اعتماد پیدا نمیکند؛ این سه، دلیل وجودی آزمون دستیاند.
- پرتکرارترین باگهای وب ایرانی در تجربهی عملی: راستیآزمایی نشدن پاسخ درگاه پرداخت در سمت سرور، افزونه‌های وصلهنشده، و فایلهای پشتیبان و
.gitرهاشده در ریشهی وب.
جدول نگاشت: کلاس باگ ← دستهی OWASP 2025 ← CWE ← شدت معمول
این جدول ستون فقرات این صفحه است. «شدت معمول» یک بازه‌ی تجربی است، نه حکم؛ شدت واقعی هر یافته با CVSS و بر پایه‌ی داده و دارایی درگیر تعیین میشود.
| کلاس باگ | دستهی OWASP 2025 | CWE | شدت معمول |
|---|---|---|---|
| IDOR / دسترسی افقی به دادهی کاربر دیگر | A01 | CWE-639، CWE-862 | بالا تا بحرانی |
| ارتقای امتیاز عمودی (کاربر ← مدیر) | A01 | CWE-269، CWE-285 | بحرانی |
| مجوزدهی فقط در رابط کاربری | A01 | CWE-602، CWE-284 | بالا |
| Mass Assignment / نوشتن فیلد غیرمجاز | A08 | CWE-915 | بالا |
| SSRF | A01 (ادغام‌شده) | CWE-918 | بالا تا بحرانی |
| CSRF | A01 (ادغام‌شده) | CWE-352 | متوسط تا بالا |
| هدرهای امنیتی غایب / فهرست دایرکتوری | A02 | CWE-16 | اطلاعاتی تا متوسط |
| اعتبارنامه‌ی پیش‌فرض یا محیط دمو در عملیات | A02 | CWE-1392، CWE-16 | بالا تا بحرانی |
| XXE در پردازش XML و فایل آپلودی | A02 | CWE-611 | بالا |
| افزونه یا کتابخانه‌ی وصلهنشده | A03 | CWE-1395، CWE-1104 | متوسط تا بحرانی |
| وابستگی بدون امضا از منبع غیررسمی | A03 / A08 | CWE-829 | بالا |
| انتقال یا ذخیره‌ی داده بدون رمزنگاری کافی | A04 | CWE-327 | متوسط تا بالا |
| هش رمز عبور بدون نمک یا با الگوریتم منسوخ | A04 | CWE-327، CWE-916 | بالا |
| تزریق SQL | A05 | CWE-89 | بالا تا بحرانی |
| XSS (بازتابی، ذخیره‌شده، DOM) | A05 | CWE-79 | متوسط تا بحرانی |
| تزریق دستور سیستم‌عامل | A05 | CWE-78 | بحرانی |
| تزریق قالب سمت سرور (SSTI) | A05 | CWE-1336 | بحرانی |
| سوءاستفاده از منطق کسبوکار | A06 | CWE-840 | متوسط تا بحرانی |
| آپلود بدون محدودیت نوع فایل | A06 | CWE-434 | بالا تا بحرانی |
| نبود قفل و محدودسازی نرخ در ورود | A07 | CWE-307 | متوسط تا بالا |
| ضعف مدیریت نشست / تثبیت نشست | A07 | CWE-384، CWE-613 | بالا |
| ضعف اعتبارسنجی JWT | A07 | CWE-287، CWE-347 | بالا تا بحرانی |
| Deserialization ناامن | A08 | CWE-502 | بحرانی |
| نبود لاگ و هشدار برای رخدادهای امنیتی | A09 | CWE-778 | متوسط |
| نشت اطلاعات در پیام خطا و Stack Trace | A10 / A02 | CWE-209، CWE-1295 | اطلاعاتی تا متوسط |
| تخلیه‌ی منابع و شکست ناامن (Fail-open) | A10 | CWE-770، CWE-636 | متوسط تا بالا |
| شرایط مسابقه (Race Condition) | A06 / A10 | CWE-362 | متوسط تا بحرانی |
A01 — کنترل دسترسی شکسته: پرحجم‌ترین دستهی یافته‌ها
چه شکلی است: برنامه شناسه‌ای را از کاربر می‌گیرد و بدون بررسی اینکه این کاربر مالک آن شیء است، آن را برمی‌گرداند یا تغییر می‌دهد. سه صورت اصلی: افقی (کاربر A به دادهی کاربر B)، عمودی (کاربر عادی به عملیات مدیر) و وابسته به زمینه (رد کردن یک گام از فرایند چندمرحلهای).
نشانه‌ها: اندپوینتی که شناسه می‌گیرد؛ مسیر مدیریتی که فقط «لینکش در منو نیست»؛ بررسی نقش در سمت مرورگر؛ کنترلی که در GET هست و در PUT و DELETE جا افتاده؛ و نسخه‌ی JSON صفحه‌ای که کنترل نسخه‌ی HTML را ندارد.
چگونه کشف میشود: با دو حساب در دو سطح دسترسی وارد می‌شویم، مجموعه‌ی کامل درخواست‌های هر کدام را ضبط می‌کنیم و هر درخواست را با نشست دیگری بازپخش می‌کنیم. افزونه‌های مقایسه‌ی مجوز در Burp Suite این کار را خودکار می‌کنند، اما تصمیم نهایی انسانی است: هیچ ابزاری نمی‌داند کاربر ۵ باید رکورد ۷ را ببیند یا نه. به همین دلیل این دسته پربازده‌ترین بخش آزمون دستی است.
«شناسه‌های ما UUID هستند، پس IDOR نداریم.» شناسهی غیرقابل حدس فقط هزینه‌ی کشف را بالا می‌برد و هیچ بررسی مجوزی اضافه نمیکند. UUIDها از پاسخ سایر اندپوینت‌ها، خروجی گزارش‌ها، هدر Referer و پروفایل‌های عمومی نشت می‌کنند. توضیح کامل در دانشنامه‌ی IDOR.
اثر واقعی: افشای انبوه دادهی مشتریان با یک حلقه روی شناسه‌ها، تغییر سفارش دیگران، و در حالت عمودی، در اختیار گرفتن پنل مدیریت.
رفع: اعمال مجوزدهی در لایه‌ی دسترسی به داده و در هر درخواست — الگوی ذهنی درست WHERE id = ? AND owner_id = ? است، نه بررسی بعد از واکشی؛ رد پیش‌فرض؛ سازوکار مرکزی و قابل استفاده‌ی مجدد به‌جای بررسی پراکنده در هر کنترلر؛ و ثبت لاگ و هشدار برای شکست‌های مجوزدهی.
دو کلاس ادغام‌شده در همین دسته: SSRF (CWE-918) که در آن سرور وادار میشود از طرف مهاجم درخواست بزند — نگاه کنید به دانشنامه‌ی SSRF — و CSRF (CWE-352) که با تکیه بر پیش‌فرض مرورگرها رفع نمی‌شود؛ توکن سمت سرور همچنان الزامی است، چون فایرفاکس پیش‌فرض SameSite=Lax را اعمال نمیکند و همین یک نکته، بخش بزرگی از محتوای قدیمی را باطل میکند (دانشنامه‌ی CSRF).
A02 — پیکربندی نادرست: ارزان‌ترین دسته برای رفع
چه شکلی است: آسیب‌پذیری در کد نیست، در تنظیمات است. OWASP این دسته را در ۲۰۲۵ از رتبه‌ی ۵ به رتبه‌ی ۲ آورد و می‌گوید در دادهی این نسخه، مثل A01، ۱۰۰٪ برنامه‌های آزموده‌شده متأثر بوده‌اند.
موارد پرتکرار در برنامه‌های وب ایرانی:
- فایلهای رهاشده در ریشهی وب:
backup.zip،db.sql،.env، دایرکتوری.git، و فایلهای*.bakویرایشگر. این‌ها با فهرست‌های واژه در ابزارهای کشف محتوا در چند دقیقه پیدا می‌شوند و اغلب کل کد و اعتبارنامه‌ها را لو می‌دهند. - محیط دمو، فاز، یا نسخه‌ی قدیمی سایت روی زیردامنه‌ای که کسی فراموشش کرده — با دادهی واقعی و بدون به‌روزرسانی.
- اعتبارنامه‌ی پیش‌فرض در پنل مدیریت، phpMyAdmin، داشبورد مانیتورینگ یا سرویس صف.
- پیام خطای پرجزئیات و Stack Trace که نام و نسخه‌ی کامپوننت‌ها را اعلام میکند.
- فهرست‌شدن دایرکتوری و دسترسی عمومی فضای ذخیره‌سازی ابری یا باکت آبجکت‌استوریج.
- هدرهای امنیتی غایب — که به‌تنهایی یافته‌ی کم‌شدتی است و نباید به‌عنوان یافته‌ی بحرانی ثبت شود، اما در ترکیب با یک XSS اثر را چند برابر میکند.
توجه کنید که XXE (CWE-611) در نسخه‌ی ۲۰۲۵ زیر همین دسته قرار دارد، نه زیر تزریق. و یک نکته‌ی فنی که محتوای قدیمی را باطل میکند: XXE در PHP نسخه‌ی ۸ به بالا و در تجزیه‌گرهای استاندارد پایتون ۳ به‌طور پیش‌فرض بسته است و libxml2 از نسخه‌ی ۲٫۹ آن را غیرفعال کرده؛ اکوسیستمی که همچنان به‌طور پیش‌فرض ناامن است، جاوا (JAXP) است. پس XXE را در پردازش SVG و OOXML و SAML و اندپوینت‌های SOAP و پشته‌های جاوا بجویید (دانشنامه‌ی XXE).
رفع: فرایند مقاوم‌سازی تکرارپذیر و یکسان در همهی محیط‌ها، پلتفرم حداقلی (حذف نمونه‌ها و ماژول‌های غیرضروری)، راستیآزمایی خودکار پیکربندی، و بازبینی دوره‌ای مجوزهای فضای ذخیره‌سازی. چک‌لیست عملی در چک‌لیست امنیتی آمده است.
A03 — نقصهای زنجیرهی تأمین: جایی که بیشترین RCE واقعی از آن می‌آید
چه شکلی است: کد شما سالم است، اما چیزی که به آن تکیه کرده‌اید نیست. این دسته جانشین «اجزای آسیب‌پذیر و قدیمی» در ۲۰۲۱ است، با دامنه‌ای گسترده‌تر: OWASP تصریح میکند اکنون «همهی نقصهای زنجیرهی تأمین را پوشش می‌دهد، نه فقط مواردی که به آسیب‌پذیری شناخته‌شده مربوط‌اند» — یعنی ابزار ساخت آلوده، خط لوله‌ی CI/CD در معرض خطر، و کانال توزیع دستکاری‌شده هم داخل آن است.
نشانه‌ها: نسخه‌ی قدیمی فریم‌ورک یا کتابخانه در فایل قفل وابستگی؛ افزونه‌ای که سال‌ها به‌روزرسانی نداشته؛ نبود فهرست دارایی نرم‌افزاری (SBOM)؛ و بارگذاری اسکریپت از CDN بدون بررسی یکپارچگی.
چگونه کشف میشود: اسکن ترکیب نرم‌افزاری روی فایلهای وابستگی، و تطبیق نسخه‌های شناسایی‌شده با پایگاه‌های CVE. اما نکته‌ی کلیدی این است که «دارای CVE» با «قابل بهرهبرداری در محیط شما» یکی نیست؛ بخش زیادی از کار، حذف موارد غیرقابل دسترس است.
اثر واقعی: بیشترین اجرای کد از راه دور (RCE) در وب امروز از همین مسیر می‌آید، نه از کد خودِ برنامه. OWASP در سناریوهای رسمی این دسته به نمونه‌های واقعی نام می‌برد: SolarWinds (۲۰۱۹) با آلوده شدن حدود ۱۸٬۰۰۰ سازمان از راه به‌روزرسانی یک تأمین‌کننده‌ی مورد اعتماد؛ Bybit (۲۰۲۵) با سرقت ۱٫۵ میلیارد دلار از طریق نرم‌افزار کیف پول مخرب؛ و Shai-Hulud (۲۰۲۵)، کرم خودتکثیر npm که بیش از ۵۰۰ نسخه‌ی بسته را آلوده کرد. در کلاس آسیب‌پذیری اجزا هم Log4Shell (CVE-2021-44228) و RCE در Struts 2 (CVE-2017-5638) مثال‌های رسمی OWASP هستند.
رفع: مدیریت متمرکز SBOM و موجودی‌برداری پیوسته؛ دریافت اجزا فقط از منابع رسمی با راستیآزمایی امضا؛ رصد هشدارهای آسیب‌پذیری؛ تفکیک وظایف و MFA در CI/CD و مخازن؛ و انتشار مرحله‌ای به‌جای استقرار هم‌زمان. در سایتهای وردپرسی، همین دسته عملاً همان مسئله‌ی افزونهها است — تفصیلش در آسیبپذیریهای وردپرس.
A05 — تزریق: قدیمی، پرحجم و همچنان زنده
تعریف رسمی OWASP: نقصی که اجازه می‌دهد ورودی نامعتمد به یک مفسر برسد و بخشی از آن به‌عنوان دستور اجرا شود. این دسته ۳۷ CWE را پوشش می‌دهد و دو سنگین‌وزنش CWE-89 با بیش از ۱۴٬۰۰۰ CVE و CWE-79 با بیش از ۳۰٬۰۰۰ CVE هستند. XSS داخل همین دسته است، نه یک دستهی مستقل.
تزریق SQL
نشانه: تغییر رفتار یا زمان پاسخ با کاراکترهای معنادار SQL. کشف: آزمون تفاوت رفتار روی همهی نقاط ورود، سپس تعیین نوع (UNION، خطامحور، بلایند بولی، بلایند زمانی، خارج‌باند، مرتبه‌دوم). نکته‌ی حرفه‌ای: کوئری پارامتری راه‌حل درست است اما شناسه‌ها (نام جدول و ستون، ORDER BY) پارامتری‌شدنی نیستند و به فهرست سفید نیاز دارند — تفصیل در تزریق SQL چیست.
XSS
نشانه: بازتاب ورودی در HTML بدون کدگذاری، یا جریان داده از location به innerHTML. کشف: تعیین زمینه‌ی بازتاب و تحلیل جریان منبع‌به‌گیرنده در جاوااسکریپت. نوع مبتنی بر DOM را اسکنرهای سمت سرور معمولاً نمی‌بینند، چون بدنه‌ی حمله اغلب در قطعه‌ی URL است و هرگز به سرور نمی‌رسد. نکته: فریم‌ورک مدرن و CSP هیچ‌کدام این کلاس را حذف نمی‌کنند — XSS چیست.
تزریق دستور و SSTI
هر دو مستقیماً به اجرای کد روی سرور می‌رسند و شدتشان تقریباً همیشه بحرانی است. تزریق دستور با متاکاراکترهای شل و — نکته‌ای که اغلب از دست می‌رود — با تزریق آرگومان رخ می‌دهد؛ یعنی حتی وقتی شلی در میان نیست، ورودی مهاجم می‌تواند سوئیچ‌های خطرناک یک ابزار خط فرمان را فعال کند. پس جمله‌ی «ما شل صدا نمی‌زنیم، پس تزریق دستور نداریم» کافی نیست (تزریق دستور).
رفع کل دسته: APIهای پارامتری و جداسازی داده از دستور؛ اعتبارسنجی مثبت (فهرست سفید) در سمت سرور؛ کدگذاری خروجی متناسب با زمینه؛ و ادغام SAST و DAST در خط لوله‌ی CI/CD.
A07 و A04 — احراز هویت، نشست و رمزنگاری
خطاهای احراز هویت (A07)
موارد پرتکرار: نبود محدودسازی نرخ و قفل شدن حساب در برابر Credential Stuffing؛ سیاست رمز عبوری که پیچیدگی را اجبار میکند و در عمل کاربر را به بازاستفاده سوق می‌دهد؛ اعتبارنامه‌ی سخت‌کدشده در کد یا مخزن؛ انقضای نادرست نشست و نبود ابطال سمت سرور پس از خروج؛ و در محیط‌های SSO، نبود خروج یکپارچه (SLO).
در سامانه‌های ایرانی دو مورد دیگر هم پرتکرار است: جریان OTP پیامکی بدون محدودیت نرخ و بدون انقضای درست کد، و شمارش‌پذیری حساب — تفاوت پیام یا زمان پاسخ بین شماره‌ی موجود و ناموجود.
برای احراز هویت مبتنی بر توکن، خطاهای JWT کلاس مستقلی‌اند: پذیرش alg: none، جانشینی الگوریتم (RS256 به HS256)، کلید متقارن ضعیف و قابل شکستن، و اعتبارسنجی‌نشدن ادعاهای aud و iss. قاعده‌ی مرجع RFC 8725 صریح است: الگوریتم را برنامه تعیین میکند، نه توکن (دانشنامه‌ی JWT).
رفع: MFA؛ پشتیبانی از مدیر رمز عبور و حذف اجبار تعویض دوره‌ای؛ بررسی رمزهای جدید در برابر مجموعه‌های فاش‌شده؛ هم‌راستایی سیاست با NIST SP 800-63B؛ محدودسازی نرخ و تأخیر در ورودهای ناموفق؛ و مدیر نشست سمت سرور با شناسهی پرآنتروپی در کوکی امن.
خطاهای رمزنگاری (A04)
موارد پرتکرار: هش رمز عبور بدون نمک یا با الگوریتم منسوخ (MD5، SHA-1)؛ نگهداری کلید در کد؛ استفاده از تولیدکننده‌ی اعداد تصادفی نامناسب برای توکن؛ و پیکربندی ضعیف TLS.
در بخش TLS، وضعیت در ۲۰۲۶ سخت‌گیرانه‌تر از محتوای رایج فارسی است: TLS 1.0 و 1.1 رسماً منسوخ‌اند، و طبق RFC منتشرشده در جولای ۲۰۲۶، در TLS 1.2 نباید مجموعه‌رمزهای RSA ایستا و خانواده‌ی FFDHE پیشنهاد یا انتخاب شوند. یعنی «TLS 1.2 داریم، پس مشکلی نیست» دیگر پاسخ کافی نیست؛ باید TLS 1.3 فعال باشد و TLS 1.2 اگر می‌ماند، محدود به ECDHE با رمزنگاری AEAD باشد (دانشنامه‌ی TLS).
A06، A08، A09 و A10 — دسته‌هایی که اسکنر نشان نمی‌دهد
طراحی ناامن و منطق کسبوکار (A06)
این دسته پرارزش‌ترین یافته‌های یک تست نفوذ حرفه‌ای را می‌سازد، چون هیچ ابزاری آن را پیدا نمیکند. نمونه‌های واقعی در برنامه‌های ایرانی:
- راستیآزمایی نشدن پاسخ درگاه پرداخت در سمت سرور. کاربر پس از پرداخت با پارامترهایی به سایت بازمی‌گردد و برنامه به همان پارامترها اعتماد میکند، به‌جای آنکه وضعیت تراکنش را با فراخوانی سرور‌به‌سرور از درگاه راستیآزمایی کند و مبلغ و شناسه را تطبیق دهد. این پرتکرارترین باگ بحرانی منطقی در فروشگاه‌های ایرانی است (امنیت فروشگاه اینترنتی).
- دستکاری مبلغ یا تعداد در سمت کلاینت و پذیرش آن در سرور؛ یا تعداد منفی که به اعتبار مثبت تبدیل میشود.
- اعمال چندباره‌ی کد تخفیف یک‌بارمصرف — که مرزش با شرایط مسابقه مشترک است.
- رد کردن یک گام از فرایند: رسیدن مستقیم به مرحله‌ی تأیید بدون گذر از اعتبارسنجی مرحله‌ی قبل.
- آپلود بدون محدودیت نوع فایل (CWE-434) که در بدترین حالت به اجرای کد می‌رسد.
نقص یکپارچگی (A08)
Deserialization ناامن (CWE-502) و Mass Assignment (CWE-915) هر دو اینجا هستند. نشانهی اولی در ترافیک، دادهی سریال‌شده‌ی قابل تشخیص است؛ نشانهی دومی، اندپوینتی که کل بدنه‌ی JSON را به مدل نگاشت میکند و پذیرش فیلدی مثل {"role":"admin"} را بررسی نکرده است.
نقص ثبت رخداد و هشدار (A09)
تغییر نام این دسته از «پایش» به «هشداردهی» عمدی است. یافته‌ی معمول: شکست‌های مجوزدهی و ورود ناموفق ثبت نمی‌شوند، لاگ‌ها بدون زمینه‌ی کافی‌اند، یا هیچ هشداری تعریف نشده. اثرش این است که رخنه ماه‌ها کشف نمی‌شود — و اگر روزی سایت هک شد، بدون لاگ، بازیابی سایت هک‌شده عملاً به حدس و گمان تبدیل میشود. یک نکته‌ی فنی مهم: خروجی لاگ باید کدگذاری شود تا تزریق به لاگ (CWE-117) رخ ندهد.
مدیریت نادرست شرایط استثنایی (A10)
دستهی کاملاً جدید ۲۰۲۵. سه سناریوی رسمی OWASP: تخلیه‌ی منابع چون استثنای آپلود گرفته میشود ولی منبع آزاد نمی‌شود؛ افشای ساختار پایگاهداده از راه مدیریت نادرست خطا که مهاجم با آن یک تزریق دقیق می‌سازد؛ و خرابی وضعیت تراکنش وقتی مهاجم عامدانه یک تراکنش چندمرحلهای را قطع میکند و از بازگشت ناقص سوءاستفاده میکند. اصل رفع در یک جمله: Fail closed، نه fail open.
شرایط مسابقه
و یک کلاس که در محتوای فارسی معمولاً «غیرعملی» توصیف میشود و این توصیف اشتباه است: شرایط مسابقه. تکنیک single-packet attack که بر پایه‌ی مالتی‌پلکسینگ HTTP/2 چند درخواست کامل را در یک بسته‌ی TCP می‌فرستد، اثر نویز شبکه را عملاً حذف میکند — پژوهش PortSwigger میانه‌ی پراکندگی یک میلی‌ثانیه را گزارش کرده در برابر چهار میلی‌ثانیه برای روش قدیمی‌تر. و رفع اشتباه رایج این کلاس، قفل در سطح برنامه است که روی چند نمونه‌ی مقیاس‌یافته کار نمیکند؛ رفع درست تراکنش پایگاهداده با سطح انزوای مناسب و به‌روزرسانی اتمی شرطی است (شرایط مسابقه).
اولویت‌بندی و رفع: با کدام باگ شروع کنیم؟
فهرست بلند یافته‌ها بدون ترتیب، عملاً بلااستفاده است. ترتیبی که در عمل جواب می‌دهد:
- هر چیزی که به اجرای کد روی سرور می‌رسد — تزریق دستور، SSTI، Deserialization ناامن، آپلود بدون محدودیت، و CVEهای RCE در اجزا. این‌ها اول.
- کنترل دسترسی روی دادهی مشتری. اثرش انبوه و بی‌سر‌و‌صداست و اسکنر پیدایش نمیکند.
- مسیر پول و احراز هویت — راستیآزمایی پرداخت، جریان OTP، بازیابی رمز، تغییر ایمیل و شماره.
- موارد پیکربندی که در چند ساعت بسته می‌شوند — حذف فایل پشتیبان و
.git، بستن دایرکتوری‌لیستینگ، خطای عمومی، تغییر اعتبارنامه‌ی پیش‌فرض. بازده به‌ازای زمان اینجا از همه بیشتر است. - موارد کم‌شدت — هدرها و نشت اطلاعات جزئی. مهم‌اند، اما نه پیش از چهار مورد بالا.
دو قاعده که تفاوت گزارش حرفه‌ای و گزارش تشریفاتی را می‌سازد. اول: WAF هیچ‌گاه راهکار رفع نیست. WAF یک کنترل جبرانی و زمان‌خر است و ساختاراً در برابر کنترل دسترسی، منطق کسبوکار، شرایط مسابقه، SSRF و بیشتر DOM XSS کور است؛ ضمن اینکه با پیدا کردن IP اصلی سرور دور زده میشود (دانشنامه‌ی WAF). دوم: هر رفع باید با آزمون مجدد تأیید شود.
برای اجرای این کاتالوگ روی سامانه‌ی خودتان، دو مسیر وجود دارد: تست نفوذ وب برای ارزیابی عمیق با اثبات اثر و شدت هر یافته، و مدیریت آسیب‌پذیری برای فرایند پیوسته‌ای که نمی‌گذارد همین یافته‌ها شش ماه بعد برگردند. اگر می‌خواهید نخست بدانید در چه وضعی هستید، بررسی امنیت سایت نقطه‌ی شروع است.
پرسش‌های متداول
باگ امنیتی سایت چه انواعی دارد؟
مرجع دستهبندی، OWASP Top 10:2025 است: کنترل دسترسی شکسته، پیکربندی نادرست، نقصهای زنجیرهی تأمین، خطاهای رمزنگاری، تزریق، طراحی ناامن، خطاهای احراز هویت، نقص یکپارچگی، نقص ثبت رخداد و هشدار، و مدیریت نادرست شرایط استثنایی. جدول این صفحه هر کلاس عملی را به دستهی OWASP و شناسهی CWE آن نگاشت کرده است.
خطرناکترین باگ سایت کدام است؟
هر باگی که به اجرای کد روی سرور برسد: تزریق دستور، SSTI، Deserialization ناامن، آپلود بدون محدودیت نوع فایل، و آسیبپذیریهای RCE در اجزای وصلهنشده. پس از آن، نقص کنترل دسترسی روی دادهی مشتری، چون اثرش انبوه است و معمولاً هیچ نشانهی ظاهری ندارد.
آیا اسکنر خودکار همهی باگهای امنیتی را پیدا میکند؟
خیر. اسکنر در پیکربندی نادرست، اجزای وصلهنشده و بخشی از تزریقها خوب است، اما کنترل دسترسی، منطق کسبوکار، شرایط مسابقه و زنجیرههای چندمرحلهای را قابل اعتماد پیدا نمیکند — چون تصمیم دربارهی «چه کسی مجاز است چه کاری بکند» بیرون از دانش ابزار است. این سه، دلیل وجودی آزمون دستیاند.
چرا SSRF در فهرست ۲۰۲۵ دستهی مستقلی ندارد؟
چون در OWASP Top 10:2025 داخل A01 کنترل دسترسی شکسته ادغام شده است؛ صفحهی رسمی A01 تصریح میکند CWE-918 اکنون زیر این دسته قرار دارد. اهمیت فنی SSRF ذرهای کم نشده و شناسهی CWE آن هم تغییر نکرده؛ فقط جای آن در تاکسونومی عوض شده است.
رایجترین باگ امنیتی سایتهای ایرانی چیست؟
در تجربهی عملی سه مورد بیش از بقیه دیده میشود: راستیآزمایی نشدن پاسخ درگاه پرداخت در سمت سرور (برنامه به پارامترهای بازگشتی اعتماد میکند)، افزونهها و کتابخانههای وصلهنشده، و فایلهای رهاشده در ریشهی وب مثل پشتیبان پایگاهداده و دایرکتوری .git. هر سه با بهرهبرداری ارزان و اثر بالا.
آیا نصب WAF کافی است تا این باگ‌ها بی‌خطر شوند؟
خیر. WAF یک کنترل جبرانی است که برای خریدن زمان تا استقرار اصلاح و مسدود کردن اسکن انبوه ارزش دارد، اما ساختاراً در برابر کنترل دسترسی، منطق کسبوکار، شرایط مسابقه، SSRF و بیشتر DOM XSS کور است و با پیدا کردن IP اصلی سرور دور زده میشود. در گزارش امنیتی، رفع یک باگ کد همیشه تغییر کد است.
منابع
علیرضا کیا
متخصص تست نفوذ وب و اندروید با سابقه‌ی مدیریت تیم نفوذ در داتین. مهندسی معکوس اپ‌ها و کشف ذخیره‌سازی ناامن، تخصص اوست.