OWASP Top 10 نسخه ۲۰۲۵؛ راهنمای عملی برای توسعه‌دهندگان وب

OWASP Top 10 معروف‌ترین فهرست ریسک‌های امنیتی وب‌اپلیکیشن‌هاست و نسخه‌ی ۲۰۲۵ آن تصویر تازه‌ای از تهدیدهای امروز ارائه می‌دهد. در این راهنما هر ده دسته را به زبان ساده توضیح می‌دهیم، برای مهم‌ترین‌ها مثال کد می‌آوریم و در پایان یک چک‌لیست عملی تحویل‌تان می‌دهیم.

بنیاد OWASP (Open Worldwide Application Security Project) یک جامعه‌ی غیرانتفاعی است و این فهرست را بر پایه‌ی داده‌های واقعی آسیب‌پذیری‌ها و نظرسنجی از متخصصان تهیه می‌کند.

فهرست کامل OWASP Top 10 نسخه ۲۰۲۵

A01: کنترل دسترسی ناقص؛ همچنان رتبه اول

رایج‌ترین شکل این مشکل «ارجاع مستقیم ناامن به شیء» یا IDOR است: کاربر شناسه‌ی داخل آدرس را عوض می‌کند و داده‌ی دیگران را می‌بیند. احراز هویت به تنهایی کافی نیست؛ باید در هر درخواست مالکیت منبع را هم بررسی کنید.

// ناامن: هر کاربر واردشده هر سفارشی را می‌بیند
app.get("/api/orders/:id", requireAuth, async (req, res) => {
  const order = await db.order.findUnique({ where: { id: req.params.id } });
  res.json(order);
});

// امن: سفارش فقط اگر متعلق به همین کاربر باشد برگردانده می‌شود
app.get("/api/orders/:id", requireAuth, async (req, res) => {
  const order = await db.order.findFirst({
    where: { id: req.params.id, userId: req.user.id },
  });
  if (!order) return res.status(404).end();
  res.json(order);
});

به‌جای ۴۰۳ از ۴۰۴ استفاده کرده‌ایم تا مهاجم حتی نفهمد چنین سفارشی وجود دارد. قاعده‌ی طلایی: پیش‌فرض، رد دسترسی است (Deny by Default).

A02: پیکربندی نادرست امنیتی

صعود این دسته به رتبه‌ی دوم تعجبی ندارد؛ نرم‌افزار امروز پر از فایل پیکربندی، کانتینر و سرویس ابری است. نمونه‌های رایج:

• حالت دیباگ روشن در محیط عملیاتی و نمایش استک‌تریس به کاربر
• باکت‌های ذخیره‌سازی ابری با دسترسی عمومی
• حساب‌ها و گذرواژه‌های پیش‌فرض
• نبود هدرهای امنیتی مثل Content-Security-Policy و Strict-Transport-Security

راه‌حل، پیکربندی به‌مثابه کد (Configuration as Code) و بازبینی خودکار آن در CI است تا هیچ محیطی دستی و متفاوت تنظیم نشود.

A03: شکست‌های زنجیره تأمین نرم‌افزار

این دسته نسخه‌ی گسترش‌یافته‌ی «اجزای آسیب‌پذیر و قدیمی» در فهرست ۲۰۲۱ است. حالا فقط کتابخانه‌ی قدیمی مسئله نیست؛ بسته‌های مخرب در npm و PyPI، تصاحب حساب نگهدارنده‌ها و آلوده شدن خط لوله‌ی ساخت هم جزو آن‌اند.

# نصب دقیق طبق lockfile؛ در CI به‌جای npm install
npm ci

# بررسی آسیب‌پذیری‌های شناخته‌شده در وابستگی‌ها
npm audit --audit-level=high

# جلوگیری از اجرای اسکریپت‌های نصب بسته‌ها در صورت نیاز
npm ci --ignore-scripts

چند عادت ساده که ریسک را به‌شدت کم می‌کند:

1. فایل lock را همیشه کامیت کنید و نسخه‌ها را سنجاق (Pin) کنید.
2. به‌روزرسانی خودکار وابستگی‌ها را با ابزارهایی مثل Dependabot یا Renovate فعال کنید، اما قبل از ادغام بازبینی کنید.
3. برای محصول خود فهرست اجزای نرم‌افزار (SBOM) تولید کنید.
4. دسترسی توکن‌های CI را حداقلی نگه دارید.

A04: شکست‌های رمزنگاری

ذخیره‌ی گذرواژه با الگوریتم‌های درهم‌سازی سریع مثل MD5 یا SHA-1، ارسال داده روی HTTP و نگهداری کلید در مخزن کد، کلاسیک‌ترین نمونه‌ها هستند. برای گذرواژه همیشه از الگوریتم‌های کند و نمک‌دار استفاده کنید:

from argon2 import PasswordHasher

ph = PasswordHasher()
hashed = ph.hash("user-password")

# هنگام ورود
try:
    ph.verify(hashed, "user-password")
except Exception:
    raise PermissionError("Invalid credentials")

A05: تزریق؛ از SQL تا دستورهای سیستم‌عامل

تزریق (Injection) وقتی رخ می‌دهد که ورودی کاربر مستقیم در کوئری یا دستور چسبانده شود. درمان قطعی، کوئری پارامتری است:

// ناامن: رشته‌سازی کوئری
const result = await pool.query(
  `SELECT * FROM users WHERE email = '${email}'`
);

// امن: کوئری پارامتری در node-postgres
const result = await pool.query(
  "SELECT * FROM users WHERE email = $1",
  [email]
);

تزریق اسکریپت بین‌سایتی (XSS) هم در همین دسته قرار می‌گیرد. فریم‌ورک‌هایی مثل React خروجی را به‌طور پیش‌فرض ایمن می‌کنند؛ پس از dangerouslySetInnerHTML فقط با داده‌ی پاک‌سازی‌شده استفاده کنید.

A06: طراحی ناامن

برخی ضعف‌ها با هیچ کد تمیزی رفع نمی‌شوند، چون در طراحی ریشه دارند؛ مثلاً فرم بازیابی رمز بدون محدودیت تعداد درخواست یا فرایند پرداختی که مرحله‌ی تأیید را می‌شود دور زد. مدل‌سازی تهدید (Threat Modeling) پیش از نوشتن کد، ابزار اصلی این دسته است.

A07: شکست‌های احراز هویت

نبود محدودیت نرخ ورود، پذیرفتن گذرواژه‌های ضعیف، نشست‌هایی که هرگز منقضی نمی‌شوند و نبود احراز هویت چندعاملی (MFA). بهترین جهش امنیتی در این دسته، حرکت به سمت ورود بدون گذرواژه است؛ در مقاله‌ی پس‌کی چیست نحوه‌ی پیاده‌سازی آن با WebAuthn را توضیح داده‌ایم.

A08: شکست یکپارچگی نرم‌افزار یا داده

اعتماد به داده‌ای که امضا یا تأیید نشده؛ مثل بارگذاری اسکریپت از CDN بدون Subresource Integrity یا از‌سریال‌خارج‌کردن (Deserialization) داده‌ی نامطمئن.

<script
  src="https://cdn.example.com/lib.min.js"
  integrity="sha384-BASE64_HASH_OF_FILE"
  crossorigin="anonymous"></script>

A09: شکست در ثبت رویداد و هشدار

اگر ورودهای ناموفق، تغییر مجوزها و خطاهای کنترل دسترسی ثبت نشوند، حمله ممکن است ماه‌ها پنهان بماند. لاگ باید ساخت‌یافته باشد، اطلاعات حساس (گذرواژه، توکن) در آن نباشد و روی رویدادهای مهم هشدار تعریف شود؛ لاگی که کسی نمی‌بیند، عملاً وجود ندارد.

A10: مدیریت نادرست شرایط استثنایی

دسته‌ی تازه‌ی نسخه‌ی ۲۰۲۵ درباره‌ی رفتار سیستم در لحظه‌ی خطاست. اصل کلیدی: ناامن شکست نخورید؛ بسته شکست بخورید (Fail Closed).

// اگر سرویس مجوز در دسترس نباشد، دسترسی باز می‌ماند
async function canAccess(user, resource) {
  try {
    return await authz.check(user, resource);
  } catch {
    return true;
  }
}

// در صورت خطا، دسترسی رد و رویداد ثبت می‌شود
async function canAccess(user, resource) {
  try {
    return await authz.check(user, resource);
  } catch (err) {
    logger.error({ err, userId: user.id }, "authz check failed");
    return false;
  }
}

چطور OWASP Top 10 را وارد فرایند توسعه کنیم؟

دانستن فهرست کافی نیست؛ باید آن را به عادت‌های روزمره‌ی تیم تبدیل کرد. چند گام عملی که در تیم‌های کوچک و بزرگ جواب داده است:

امنیت در بازبینی کد

یک قالب ساده برای درخواست ادغام (Pull Request) بسازید که چند سؤال امنیتی ثابت دارد: «آیا endpoint جدید مالکیت منبع را بررسی می‌کند؟»، «ورودی کاربر کجا وارد کوئری یا دستور می‌شود؟»، «چه چیزی لاگ می‌شود؟». همین چند سؤال، بخش بزرگی از باگ‌های A01 و A05 را پیش از ادغام پیدا می‌کند.

ابزارهای خودکار در CI

• تحلیل ایستای کد (SAST) برای یافتن الگوهای خطرناک مثل رشته‌سازی کوئری.
• تحلیل ترکیب نرم‌افزار (SCA) برای شناسایی وابستگی‌های آسیب‌پذیر.
• تحلیل پویا (DAST) روی محیط آزمایشی برای یافتن پیکربندی نادرست و هدرهای جاافتاده.
• اسکن اسرار تا هیچ کلید API یا گذرواژه‌ای وارد مخزن نشود.

قهرمان امنیت در هر تیم

لازم نیست همه متخصص امنیت باشند؛ کافی است در هر تیم یک نفر «قهرمان امنیت» (Security Champion) باشد که آموزش بیشتری دیده و در طراحی‌ها و بازبینی‌ها نظر امنیتی می‌دهد. این نقش، فاصله‌ی تیم امنیت و تیم توسعه را کم می‌کند.

از Top 10 به ASVS

وقتی تیم با این فهرست راحت شد، سراغ استاندارد تأیید امنیت اپلیکیشن (ASVS) بروید. ASVS برخلاف Top 10 که یک سند آگاهی‌بخش است، فهرست دقیقی از الزامات قابل‌آزمون ارائه می‌دهد و برای تعریف معیار پذیرش امنیتی پروژه‌ها مناسب است.

چک‌لیست عملی برای تیم‌های توسعه

• بررسی مالکیت منبع در همه‌ی endpointها
• حالت دیباگ خاموش و هدرهای امنیتی فعال در محیط عملیاتی
• npm ci یا معادل آن و اسکن وابستگی‌ها در CI
• درهم‌سازی گذرواژه با Argon2 یا bcrypt
• کوئری پارامتری در همه‌ی دسترسی‌ها به پایگاه داده
• محدودیت نرخ روی ورود و بازیابی رمز
• لاگ ساخت‌یافته و هشدار برای رویدادهای امنیتی
• رفتار Fail Closed در همه‌ی مسیرهای مجوزدهی

جمع‌بندی

OWASP Top 10 نسخه‌ی ۲۰۲۵ پیام روشنی دارد: امنیت دیگر فقط به کدی که خودمان می‌نویسیم محدود نیست؛ پیکربندی، وابستگی‌ها و رفتار سیستم هنگام خطا به همان اندازه مهم‌اند. این فهرست را نقطه‌ی شروع بدانید و برای عمق بیشتر سراغ مجموعه‌ی Cheat Sheet و استاندارد ASVS بروید.