OWASP Top 10 مهم‌ترین مرجع عمومی برای شناخت ریسک‌های امنیتی وب‌اپلیکیشن است. این فهرست استاندارد قانونی نیست و چک‌لیستی هم نیست که با تیک زدنش نرم‌افزار امن شود. ارزشش این است که نشان می‌دهد تیم‌ها بیشتر از همه کجا آسیب می‌بینند و زبان مشترکی میان مدیر، توسعه‌دهنده و تست‌کننده می‌سازد.

فهرست نسخه ۲۰۲۵

ده دسته این نسخه در سایت رسمی OWASP به این ترتیب آمده است:

  1. A01: Broken Access Control، نقص در کنترل دسترسی
  2. A02: Security Misconfiguration، پیکربندی نادرست
  3. A03: Software Supply Chain Failures، ضعف زنجیره تأمین نرم‌افزار
  4. A04: Cryptographic Failures، ضعف در رمزنگاری
  5. A05: Injection، تزریق
  6. A06: Insecure Design، طراحی ناامن
  7. A07: Authentication Failures، ضعف در احراز هویت
  8. A08: Software or Data Integrity Failures، ضعف در یکپارچگی نرم‌افزار یا داده
  9. A09: Security Logging and Alerting Failures، ضعف در ثبت رویداد و هشدار
  10. A10: Mishandling of Exceptional Conditions، مدیریت نادرست شرایط استثنایی

سه تغییری که بیشتر به کار می‌آید

زنجیره تأمین حالا جای خودش را دارد

نرم‌افزار امروز بیشتر از کدی ساخته می‌شود که خودتان ننوشته‌اید. کتابخانه‌ها، ابزارهای ساخت و سرویس‌های بیرونی همه بخشی از محصول شما هستند. اگر یکی از آن‌ها آلوده شود، کد خود شما هرچقدر هم تمیز باشد، آسیب می‌بینید. برای همین قفل کردن نسخه‌ها، بررسی به‌روزرسانی‌ها و محدود کردن دسترسی ابزارهای ساخت دیگر کار لوکسی نیست.

پیکربندی نادرست بالاتر آمده است

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

رفتار هنگام خطا هم امنیت است

دسته تازه A10 می‌پرسد نرم‌افزار وقتی چیزی طبق برنامه پیش نمی‌رود چه می‌کند. سیستمی که هنگام خطای پایگاه داده دسترسی را باز می‌گذارد، یا متن کامل خطا را به کاربر نشان می‌دهد، حتی اگر مسیر عادی‌اش بی‌نقص باشد ضعف دارد. قاعده ساده است: هنگام شک، دسترسی را ببندید و جزئیات فنی را فقط در لاگ نگه دارید.

از کجا شروع کنیم

اگر وقت و بودجه محدود است، این ترتیب برای بیشتر محصولات منطقی است:

  • کنترل دسترسی را در سرور بررسی کنید. برای هر مسیر حساس بپرسید اگر کاربر دیگری همین نشانی را صدا بزند چه می‌شود. پنهان کردن یک دکمه در رابط کاربری کنترل دسترسی نیست.
  • تنظیمات محیط واقعی را مرور کنید. حالت دیباگ، رمزهای پیش‌فرض، پورت‌های باز و هدرهای امنیتی را چک کنید.
  • وابستگی‌ها را بشناسید. بدانید چه کتابخانه‌هایی دارید و کدام‌ها آسیب‌پذیری شناخته‌شده دارند.
  • لاگ و هشدار بگذارید. اگر نفوذی رخ دهد و کسی خبردار نشود، آسیب چند برابر می‌شود.
  • برای خطا تست بنویسید. فقط مسیر موفق را تست نکنید. قطع شدن سرویس بیرونی و ورودی نامعتبر را هم بسنجید.

این فهرست چه چیزی را به شما نمی‌گوید

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

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

منابع