OWASP Logo

أهم 10 ثغرات في تطبيقات الويب على حسب OWASP

١٢ مارس ٢٠٢٥

مؤسسة OWASP كل فترة بتحدّث قائمة بأخطر الثغرات الأمنية الموجودة في تطبيقات الويب، وهاي الثغرات إذا ما انتبهتلها، ممكن تعرّض موقعك للاختراق. تعالوا نشوف كل وحدة مع أمثلة عملية!

ملاحظة: هاي الثغرات في المقال هاد من موقع OSWAP واخر تحديث ل البيانات هاي كان ب September 2024 و من المتوقع انو ينزلو ريبورت جديد في النصف الأول من 2025.
تقرير OWASP


التحكم الفاشل في الوصول – Broken Access Control

شو يعني؟
هي لما الموقع ما بيكون عنده تحكم صحيح بالصلاحيات، فالمستخدم العادي بقدر يوصل لمناطق إدارية أو بيانات مش لازم يشوفها!

مثال واقعي:

تخيل عندك موقع إدارة طلاب، وعندك طالب ومدير. إذا الطالب كتب هالرابط في المتصفح:
https://school.com/admin
وقدر يوصل لصفحة الأدمن بدون تسجيل دخول… هون في ثغرة Broken Access Control!

كيف نحلها؟

    • لازم كل طلب يتم فحص الصلاحيات تبعته.
    • استخدم Token-based Authentication أو RBAC (Role-Based Access Control).

فشل في التشفير – Cryptographic Failures

شو يعني؟
الموقع بيستخدم تشفير ضعيف أو ما بيشفّر البيانات الحساسة نهائيًا.

مثال واقعي:

    • تخزين كلمات السر بدون تشفير في قاعدة البيانات.
    • استخدام خوارزميات قديمة زي MD5 وSHA1 اللي صار سهل كسرهم.

كيف نحلها؟

    • لازم تستخدم Bcrypt أو Argon2 بدلًا من MD5.
    • شفر كل البيانات الحساسة، وما تخزن كلمات السر كنص عادي.

حقن الأكواد – Injection (مثل SQL Injection وXSS)

شو يعني؟
الموقع بيسمح للمستخدمين يدخلوا بيانات بدون تصفية، فبالتالي الهاكر بقدر يحقن أوامر SQL أو JavaScript داخل المدخلات.

مثال واقعي: إذا عندك صفحة تسجيل دخول، وفي خانة اليوزر نيم كتب الهاكر: ' OR '1'='1 هنا الموقع رح يعتبره كود SQL، ويدخل الهاكر بدون كلمة سر!

كيف نحلها؟

    • استخدم Prepared Statements بدلًا من تنفيذ الاستعلامات العادية.
    • افحص كل المدخلات ونظّفها قبل تنفيذها.

تصميم غير آمن – Insecure Design

شو يعني؟
الموقع نفسه مصمم بشكل ضعيف أمنيًا، حتى لو الكود نفسه ما فيه ثغرات واضحة.

مثال واقعي:

    • عدم وجود نظام تأمين إضافي بعد محاولات تسجيل دخول فاشلة زي انو ما احط ليميت على عدد المحاولات لتسجيل الدخول وهاد بيتيح للمستخدم عدد لا نهائي من المحاولات (Brute Force Attack).
    • عدم وجود عملية تحقق إضافية عند تغيير الإيميل أو كلمة السر.

كيف نحلها؟

    • لازم يكون فيه 2FA (توثيق بخطوتين) للأشياء الحساسة.
    • مراجعة التصميم الأمني للمشروع قبل ما تبلّش البرمجة.

أخطاء في ضبط الأمان – Security Misconfiguration

شو يعني؟
الموقع عنده إعدادات افتراضية خطيرة، زي ترك لوحة التحكم مفتوحة أو إعطاء معلومات كثيرة بالأخطاء.

مثال واقعي:

    • ترك وضع Debug مفعّل في الإنتاج، فلو صار خطأ في الموقع، بيظهر كود السيرفر للمستخدمين!
    • قاعدة بيانات مفتوحة للإنترنت بدون كلمة سر.

كيف نحلها؟

    • لازم تعمل مراجعة أمنية قبل نشر الموقع.
    • أغلق المنافذ والخدمات غير المستخدمة.

استخدام مكونات غير محدثة – Vulnerable & Outdated Components

شو يعني؟
استخدام مكتبات وبرمجيات قديمة فيها ثغرات معروفة.

مثال واقعي: إذا بتستخدم jQuery إصدار قديم، ممكن يكون عنده ثغرات معروفة وسهلة الاختراق.

كيف نحلها؟

    • استخدم أدوات مثل npm audit أو Snyk لفحص التحديثات.
    • حدّث كل المكتبات وأطراف المشروع باستمرار.

مشاكل في التحقق والتوثيق – Identification & Authentication Failures

شو يعني؟
الموقع عنده مشاكل في تسجيل الدخول، التحقق من الهويات، أو إدارة الجلسات.

مثال واقعي:

    • السماح للمستخدمين بتعيين كلمة سر ضعيفة جدًا مثل "123456".
    • استخدام JWT tokens بدون توقيع أو تشفير.

كيف نحلها؟

    • فرض كلمات سر قوية وسياسات تسجيل دخول جيدة.
    • استخدام توثيق بخطوتين (2FA).

فشل في سلامة البرمجيات والبيانات – Software & Data Integrity Failures

شو يعني؟
الموقع بيسمح بتحميل أو تشغيل ملفات ومكونات من مصادر غير موثوقة.

مثال واقعي:

    • تحديثات البرامج يتم تحميلها بدون التحقق من توقيعها الأمني.
    • السماح للمستخدم برفع ملفات بدون فحصها.

كيف نحلها؟

    • استخدم توقيع رقمي للتحقق من تحديثات البرامج.
    • افحص الملفات المرفوعة قبل السماح بتنفيذها.

فشل في تسجيل الأحداث والمراقبة – Security Logging & Monitoring Failures

شو يعني؟
الموقع ما بيحتفظ بسجلات للأحداث الأمنية، فبالتالي أي هجوم ممكن يصير من غير ما حد يعرف.

مثال واقعي:

    • ما في Logs لمحاولات تسجيل الدخول الفاشلة.
    • ما في نظام إنذار عند اكتشاف هجوم أو نشاط مشبوه.

كيف نحلها؟

    • أضف نظام مراقبة Logs.
    • استخدم SIEM أو Cloudwatch لمراقبة الأحداث الأمنية.

هجوم تزوير الطلبات من السيرفر – Server-Side Request Forgery

شو يعني؟
لما الموقع يسمح للمستخدم إنه يطلب بيانات من سيرفرات داخلية بدون فحص، وهاد الشيء ممكن يسمح للهاكر بالوصول إلى بيانات حساسة أو حتى تنفيذ أوامر داخل السيرفر.

مثال واقعي: لو عندك نظام بيسمح للمستخدم إنه يدخل رابط صورة، والهاكر بدل الصورة دخل:

http://internal-server/admin

الموقع رح يقرأ محتوى صفحة الأدمن بدون ما يتأكد!

كيف نحلها؟

    • امنع طلبات السيرفر الداخلي.
    • استخدم قوائم بيضاء (Whitelist) لعناوين الـ URLs المسموح بها.

خلاصة الموضوع:

  • كل نقطة من هاي الثغرات ممكن تكون بوابة لاختراق موقعك أو تسرّب بيانات المستخدمين، لذلك لازم دايمًا:
    تفحص الكود والمكتبات باستمرار.
  • تتبع أفضل ممارسات الأمن السيبراني.
  • تستخدم أدوات مثل OWASP ZAP وBurp Suite لفحص الثغرات.