OWASP Top 10 قائمة بأخطر عشرة مخاطر أمنية في تطبيقات الويب، تنشرها مؤسسة OWASP غير الربحية (المشروع العالمي المفتوح لأمان التطبيقات). ويشرح هذا المقال الإصدار الحالي، OWASP Top 10 2025، بكلمات بسيطة: ماذا يعني كل خطر لتطبيق أعمال، وكيف يحدث الخلل، وما الذي تسأل عنه مطوّريك، وأين يزيد الكود المكتوب بالذكاء الاصطناعي من احتماله.
لا تحتاج إلى قراءة الكود لتستفيد منها. فإن كان عملك يعتمد على بوابة للعملاء، أو متجر إلكتروني، أو نظام تخطيط موارد المؤسسة (ERP) مثل أودو مع وحدات مخصّصة، أو تطبيق بناه أحدهم بأداة ذكاء اصطناعي، فمن هذه المخاطر العشرة تبدأ معظم الاختراقات الفعلية.
ما هي قائمة OWASP Top 10
تنشر OWASP القائمة منذ 2003 وتحدّثها كل بضع سنوات. ويستند إصدار 2025، الذي أُعلن في نوفمبر 2025، إلى بيانات اختبار من أكثر من 2.8 مليون تطبيق قدّمتها شركات أمنية، إضافة إلى استطلاع لآراء المختصين حول مخاطر لا تُظهرها بيانات الاختبار جيداً. وتجمع كل فئة نقاط ضعف محددة كثيرة (248 في المجموع في هذا الإصدار)، فقد يغطي عنوان واحد عشرات الطرق التي يقع بها الخلل نفسه.
بالمقارنة مع قائمة 2021 هناك أمران جديدان، فإخفاقات سلسلة توريد البرمجيات (Software Supply Chain) صار لها مكانها الخاص في المرتبة الثالثة، وانضم سوء التعامل مع الحالات الاستثنائية (Mishandling of Exceptional Conditions) في المرتبة العاشرة. كما صعد سوء إعداد الأمان (Security Misconfiguration) من المرتبة الخامسة إلى الثانية. أما تزوير الطلبات من جهة الخادم (Server-Side Request Forgery)، الذي كان بنداً مستقلاً في 2021، فصار جزءاً من التحكم في الوصول المعطّل (Broken Access Control).
قائمة OWASP Top 10 2025 بالترتيب، مع وصف موجز لكل فئة.
المخاطر العشرة، واحداً تلو الآخر
A01:2025 التحكم في الوصول المعطّل (Broken Access Control)
يحدّد التحكم في الوصول من يستطيع رؤية ماذا وتغييره، ويكون معطّلاً حين يصل مستخدم إلى بيانات أو إجراءات تخصّ غيره. وقد احتلّ المرتبة الأولى منذ 2021.
مثال شائع: يفتح عميل الفاتورة 1043 في بوابتك، ثم يغيّر الرقم في شريط العنوان إلى 1044 فيرى فاتورة شركة أخرى. فالصفحة تحقّقت من أن المستخدم سجّل دخوله، لكنها لم تتحقق أبداً من أن الفاتورة تخصّه.
// Any logged-in user can read any invoice by changing the number
app.get("/api/invoices/:id", requireLogin, async (req, res) => {
res.json(await db.invoices.findById(req.params.id));
});
// Fixed: the invoice must belong to the user's own company
app.get("/api/invoices/:id", requireLogin, async (req, res) => {
const invoice = await db.invoices.findOne({
id: req.params.id,
companyId: req.user.companyId,
});
if (!invoice) return res.status(404).end();
res.json(invoice);
});في أودو يظهر الخطأ نفسه حين يعمل كود مخصّص باستخدام sudo()، الذي يتخطّى قواعد الوصول التي وضعها مسؤولو النظام عندك، ثم يسلّم النتيجة لمستخدم البوابة.
اسأل مطوّريك: هل تُفحص كل صلاحية على الخادم مع كل طلب، أم أنها مخفية في الشاشات فقط؟ هل يمكنكم أن تُروني اختباراً يحاول فيه عميل فتح سجل عميل آخر؟ مع الكود المكتوب بالذكاء الاصطناعي: تتكرّر هذه الثغرة مرة بعد مرة في الأبحاث المنشورة عن التطبيقات المبنية بالذكاء الاصطناعي، فالأداة تبني الشاشة التي طلبتها ونادراً ما تسأل لمن يجب أن تعرض البيانات. وفي 2025 وجد باحث 170 تطبيقاً من معرض Lovable العام يستطيع أي شخص قراءة قواعد بياناتها أو تغييرها، لأن قواعد الوصول كانت غائبة (CVE-2025-48757).
A02:2025 سوء إعداد الأمان (Security Misconfiguration)
قد يكون البرنامج سليماً ومع ذلك تتركه إعداداته مكشوفاً، كأن تبقى كلمات المرور الافتراضية، أو يُترك وضع التصحيح (Debug) مفعّلاً في بيئة الإنتاج، أو تكون صفحات الإدارة متاحة من الإنترنت، أو يُضبط التخزين السحابي على أنه عام، أو تعرض صفحات الأخطاء تفاصيل عمل النظام الداخلية.
مثال: نسخة تجريبية من نظامك، فيها نسخة حقيقية من قاعدة بيانات العملاء، تُترك على الإنترنت بكلمة مرور المسؤول الافتراضية لأنها «للتجربة فقط».
اسأل مطوّريك: كيف نتأكد أن إعدادات الإنتاج هي نفسها في كل مرة ننشر فيها؟ ومن يتحقق من أن خوادم الاختبار ومساحات التخزين ليست عامة؟ مع الكود المكتوب بالذكاء الاصطناعي: كثيراً ما تختار الأدوات إعدادات تجعل الأمور تعمل بسرعة، مثل السماح بالطلبات من أي موقع أو ترك مخرجات التصحيح مفعّلة، ولا يعيدها أحد إلى وضعها ما لم تكن على قائمة تحقق.
A03:2025 إخفاقات سلسلة توريد البرمجيات (Supply Chain Failures)
تُبنى التطبيقات الحديثة في معظمها من أجزاء خارجية، كالحزم مفتوحة المصدر والإضافات وأدوات البناء والخدمات المستضافة. وتغطي هذه الفئة خطر أن يكون أحد هذه الأجزاء قديماً أو مهجوراً أو مسموماً عمداً. ففي 2025 نشرت دودة تنتشر ذاتياً تُعرف باسم Shai-Hulud نسخاً خبيثة من مئات حزم npm، وهو مخزن المكتبات الذي يعتمد عليه مطوّرو JavaScript، وسرقت رموز الوصول (Access Tokens) الخاصة بالمطوّرين الذين ثبّتوها.
مثال: يستخدم متجرك الإلكتروني إضافة دفع لم يحدّثها أحد منذ سنوات، ثم يُكشف عن ثغرة فيها علناً فتتبعها هجمات آلية، ولم يكن أحد في فريقك يعلم أن الإضافة موجودة أصلاً.
اسأل مطوّريك: هل لدينا قائمة بكل مكوّن نستخدمه مع إصداره؟ وما سرعة تطبيقنا للتحديثات الأمنية، ومن يتلقى التنبيهات؟ مع الكود المكتوب بالذكاء الاصطناعي: تقترح أدوات الذكاء الاصطناعي إصدارات من بيانات تدريبها وقد تكون قديمة، وأحياناً تخترع أسماء حزم غير موجودة، فيسجّل المهاجمون هذه الأسماء وينتظرون. ولهذه الحيلة اسم أيضاً هو Slopsquatting، ونتناولها في مقالنا عن المخاطر الأمنية للكود المكتوب بالذكاء الاصطناعي.
A04:2025 إخفاقات التشفير (Cryptographic Failures)
يحمي التشفير البيانات بخلطها بحيث لا يقرؤها إلا الأشخاص المعنيون. ويفشل حين تنتقل البيانات الحساسة أو تُخزَّن دون حماية، أو حين تُحفظ كلمات المرور بصيغة يمكن عكسها، أو حين تُترك المفاتيح السرية في مكان يستطيع الآخرون العثور عليها فيه.
مثال: تُنسخ نسخة احتياطية من قاعدة البيانات إلى مجلد مشترك، وكانت كلمات المرور فيها مخزّنة بطريقة قديمة (MD5) يمكن كسرها في دقائق، وكثير من عملائك يستخدمون كلمة المرور نفسها في أماكن أخرى.
اسأل مطوّريك: كيف تُخزَّن كلمات المرور؟ هل كل حركة البيانات مشفّرة، بما فيها ما يجري بين خوادمنا؟ وأين توجد المفاتيح السرية، ومن يستطيع قراءتها؟ مع الكود المكتوب بالذكاء الاصطناعي: من الشائع أن تُلصق المفاتيح مباشرة في الكود، كما أن الأمثلة القديمة التي تعلّمت منها الأدوات ما زالت تستخدم طرق تجزئة (Hashing) ضعيفة.
A05:2025 الحقن (Injection)
يحدث الحقن (Injection) حين يُعامَل نص كتبه المستخدم على أنه أمر. والمثال التقليدي هو حقن SQL (SQL Injection)، حيث يسمح مربع بحث أو نموذج تسجيل دخول لشخص ما بتشغيل استعلامه الخاص على قاعدة البيانات. ويدخل في هذه الفئة أيضاً البرمجة عبر المواقع (Cross-Site Scripting)، حيث يزرع زائر كوداً يعمل في متصفحات المستخدمين الآخرين.
# Unsafe: the search text becomes part of the SQL command
cur.execute(f"SELECT * FROM customers WHERE name LIKE '%{term}%'")
# Safe: the database receives the text only as data
cur.execute("SELECT * FROM customers WHERE name LIKE %s", (f"%{term}%",))وهناك ثغرة قريبة منها في JavaScript، هي تلوّث النموذج الأولي (Prototype Pollution)، تتيح لمدخلات مصمَّمة بعناية أن تغيّر سلوك التطبيق كله، ونشرحها في تلوّث النموذج الأولي في JavaScript.
اسأل مطوّريك: هل نستخدم دائماً الاستعلامات ذات المعاملات (Parameterized Queries) وآليات التهريب (Escaping) الخاصة بإطار العمل؟ وهل تُفحص المدخلات على الخادم كما تُفحص في النموذج؟ مع الكود المكتوب بالذكاء الاصطناعي: كثيراً ما تبني الحلول السريعة الاستعلامات بلصق النصوص بعضها ببعض، خصوصاً في التقارير المخصّصة وميزات البحث، لذلك تحتاج إلى مراجعة ثانية.
A06:2025 التصميم غير الآمن (Insecure Design)
بعض الثغرات ليست أخطاء برمجية أصلاً، فالميزة تعمل تماماً كما بُنيت، لكن أحداً لم يفكّر في طرق إساءة استخدامها.
مثال: رمز خصم مخصّص لاستخدام واحد لكل عميل يمكن تطبيقه مرة بعد مرة بفتح عدة نوافذ في المتصفح في الوقت نفسه. أو تطلب إعادة تعيين كلمة المرور الإجابة عن سؤال أمان جوابه موجود في حساب المستخدم على وسائل التواصل الاجتماعي.
اسأل مطوّريك: في أهم مسارات العمل لدينا (المدفوعات والمبالغ المستردّة والموافقات وتغييرات الحسابات)، ما الذي قد يحاوله مستخدم غير نزيه، وما الذي يمنعه؟ مع الكود المكتوب بالذكاء الاصطناعي: تبني الأداة ما يصفه الطلب، فإن لم يكتب أحد حالات إساءة الاستخدام فلن تُعالَج.
A07:2025 إخفاقات المصادقة (Authentication Failures)
المصادقة هي الطريقة التي يعرف بها النظام من أنت. وتفشل حين يستطيع المهاجمون تخمين كلمات المرور أو إعادة استخدامها دون حدّ، أو حين لا تنتهي الجلسات أبداً، أو حين لا توجد خطوة ثانية للحسابات الحساسة، مثل رمز يصل إلى هاتفك.
مثال: يأخذ مهاجم قائمة برسائل بريد إلكتروني وكلمات مرور مسرّبة من موقع آخر ويجرّبها على بوابتك، بالآلاف كل ساعة. ولا شيء يبطئه، فتفتح كل كلمة مرور مُعاد استخدامها حساباً.
اسأل مطوّريك: هل نحدّ من محاولات الدخول الفاشلة؟ هل لدى المسؤولين ومستخدمي المالية مصادقة ثنائية (Two-Factor Authentication)؟ هل تنتهي الجلسات بعد تسجيل الخروج وبعد فترة من عدم النشاط؟ مع الكود المكتوب بالذكاء الاصطناعي: أنظمة تسجيل الدخول المصنوعة يدوياً تشكّل خطراً، والاعتماد على مكتبة أو مزوّد مجرَّب لتسجيل الدخول أكثر أماناً في العادة من كود يُولَّد من الصفر.
A08:2025 إخفاقات سلامة البرمجيات أو البيانات (Software or Data Integrity Failures)
تتعلق هذه الفئة بالوثوق ببيانات أو تحديثات دون التحقق من أنها تأتي فعلاً من المصدر الذي تدّعيه. وهي تتداخل مع سلسلة التوريد لكنها تركّز على تطبيقك أنت، كالتحديثات غير الموقّعة، أو الإضافات المحمَّلة من أماكن مجهولة، أو البيانات الخارجية المقبولة كأنها آمنة.
مثال: يعتبر متجرك الطلب مدفوعاً حين تصله رسالة من مزوّد الدفع. فإن لم يتحقق التطبيق من التوقيع على تلك الرسالة، يستطيع أي شخص يعرف العنوان أن يرسل إشعاراً مزيّفاً بأن «الدفعة وصلت» ويحصل على البضاعة مجاناً.
اسأل مطوّريك: هل نتحقق من كل Webhook ومن كل تحديث نثبّته؟ وهل يستطيع أي شخص تغيير عملية البناء أو النشر لدينا دون أن يراه شخص ثانٍ؟ مع الكود المكتوب بالذكاء الاصطناعي: كثيراً ما يُغفَل التحقق من التوقيع على الـWebhooks في عمليات الربط السريعة، لأن العرض التجريبي يعمل من دونه.
A09:2025 إخفاقات التسجيل الأمني والتنبيه (Security Logging & Alerting Failures)
إن لم يسجّل أحد ما يجري في النظام ويراقبه، تمرّ الهجمات دون أن يلاحظها أحد لأشهر. وقد غيّر إصدار 2025 اسم هذه الفئة ليؤكد أهمية التنبيه، لأن السجلات التي لا يراجعها أحد لا توقف شيئاً.
مثال: يجرّب شخص ألف كلمة مرور على حساب المسؤول طوال الليل وينجح في الدخول أخيراً. وقد سُجّلت المحاولات، لكن أي تنبيه لم يصدر، فيُكتشف الاختراق بعد أسابيع حين يشتكي أحد العملاء.
اسأل مطوّريك: هل نسجّل عمليات الدخول والمحاولات الفاشلة وتغييرات الصلاحيات والمعاملات الكبيرة؟ من يتلقى التنبيه، وبأي سرعة؟ وكم من الوقت نحتفظ بالسجلات، وهل يستطيع المهاجم حذفها؟ مع الكود المكتوب بالذكاء الاصطناعي: نادراً ما تضيف أدوات الذكاء الاصطناعي سجلات تدقيق أو تنبيهات ما لم يُطلب منها ذلك، وحين تسجّل فإنها أحياناً تحفظ كلمات مرور أو بيانات شخصية لا مكان لها هناك.
A10:2025 سوء التعامل مع الحالات الاستثنائية (Mishandling of Exceptional Conditions)
هذه الفئة جديدة في 2025، وتغطي ما يفعله التطبيق حين يحدث أمر غير متوقع، كأن تتوقف خدمة، أو يكون الملف كبيراً جداً، أو تصل المدخلات بصيغة خاطئة، أو تفشل خطوة في منتصفها. فالأخطاء التي لا تُعالَج جيداً قد تُسقط النظام، أو تكشف تفاصيله الداخلية، أو تترك البيانات في حالة غير سليمة.
مثال: مسار دفع يسحب المال من حساب، ثم يفشل قبل تسجيله في الحساب الآخر، ولا يتراجع عن الخطوة الأولى. أو يقع خطأ أثناء التحقق من صلاحية فيُلتقط ويُتجاهَل، ويتابع التطبيق كأن التحقق نجح. ويسمّي أهل الأمن هذا «الفشل المفتوح» (Failing Open).
اسأل مطوّريك: حين تفشل خطوة في منتصف معاملة، هل تُلغى المعاملة كلها؟ وهل تُخفي رسائل الخطأ الموجّهة للمستخدمين التفاصيل التقنية؟ مع الكود المكتوب بالذكاء الاصطناعي: كثيراً ما يلفّ الكود المولَّد المشكلات في معالجة عامة تُخفي الخطأ وتتابع العمل، فيبدو التطبيق مستقراً وهو يفعل الشيء الخاطئ.
كيف تستخدم القائمة
تصف OWASP قائمة Top 10 بأنها وثيقة توعية، وهي طريقة جيدة لبدء الحديث مع فريقك أو مع أحد المورّدين، ولإدراج الأمان في متطلبات المشروع، ولتحديد أين تبحث أولاً. لكنها ليست معياراً كاملاً، وتقول OWASP نفسها إن استخدامها معياراً للبرمجة أو الاختبار هو الحدّ الأدنى فقط.
وللفحص الأعمق تشير OWASP إلى معيار التحقق من أمان التطبيقات (ASVS)، الذي وصل الآن إلى الإصدار 5.0. ويحوّل ASVS هذه المواضيع إلى مئات المتطلبات المحددة القابلة للاختبار، موزّعة على ثلاثة مستويات، فتختار عمق الفحص بحسب حساسية التطبيق، إذ تحتاج بوابة تحمل بيانات الرواتب إلى أكثر مما يحتاجه موقع تعريفي. كما تنشر OWASP قوائم منفصلة لتطبيقات الهاتف وللتطبيقات المبنية على النماذج اللغوية الكبيرة.
تخبرك Top 10 بما يجب أن يقلقك، ويعطيك ASVS متطلبات تستطيع الاختبار على أساسها.
ومن الطرق العملية للبدء، حتى لو لم تكن تقنياً، أن ترسل أسئلة «اسأل مطوّريك» العشرة أعلاه إلى من يبني نظامك أو يصونه، وترى مدى وضوح أجوبته. ويمكنك أيضاً إجراء فحص الجاهزية للإطلاق المجاني، وهو عشرة أسئلة تستغرق نحو دقيقتين، لترى أين تقف الأساسيات.
ما الذي تغطيه المراجعة الأمنية
تجد أدوات الفحص الآلية بعض هذه المشكلات، وفي الغالب المكوّنات القديمة والإعدادات الناقصة والحقن البسيط. لكنها لا تستطيع أن تحكم إن كان يحق لمستخدم رؤية سجل ما، أو إن كان يمكن إساءة استخدام خصم، أو إن كان خطأ ما يترك حساباتك في حالة غير سليمة. وهذا يحتاج إلى أشخاص يقرؤون الكود ويختبرون التطبيق كما يفعل المهاجم.
تنظر المراجعة المفيدة إلى التطبيق ككل، أي قواعد الوصول، وتسجيل الدخول، وطريقة تخزين البيانات وإرسالها، والمكوّنات الخارجية، وإعدادات الخوادم، ومسارات العمل التي تتعامل مع المال أو البيانات الشخصية. وما يهمّ صاحب العمل أكثر هو ما يخرج به، فيجب أن تحصل على تقرير مكتوب يعرض كل مشكلة مع الدليل عليها، ويشرح ما قد تكلّفه، ويرتّب الإصلاحات حتى يعرف فريقك بماذا يبدأ. وينبغي أن يستطيع مطوّروك إعادة إنتاج كل نتيجة، فلا يضطر أحد إلى قبول التقرير على الثقة.
الأسئلة الشائعة
ما هي قائمة OWASP Top 10؟
هي قائمة بأخطر عشرة مخاطر في تطبيقات الويب، تنشرها OWASP، وهي مؤسسة غير ربحية. ويستخدمها المطوّرون والمدقّقون والمشترون نقطة انطلاق مشتركة لأمان التطبيقات.
ما الذي تغيّر في OWASP Top 10 2025؟
هناك فئتان جديدتان، هما إخفاقات سلسلة توريد البرمجيات (A03) وسوء التعامل مع الحالات الاستثنائية (A10). وصعد سوء إعداد الأمان إلى المرتبة الثانية، وصار تزوير الطلبات من جهة الخادم جزءاً من التحكم في الوصول المعطّل، الذي بقي في المرتبة الأولى.
هل توجد شهادة أو امتثال لقائمة OWASP Top 10؟
لا. فـOWASP لا تمنح شهادات للتطبيقات أو الشركات وفق قائمة Top 10. وقد يسألك العملاء والمدقّقون كيف تتعامل مع كل خطر، وللحصول على أساس رسمي قابل للاختبار توصي OWASP بمعيارها ASVS.
هل تنطبق OWASP Top 10 على أودو وأنظمة ERP الأخرى؟
نعم. فأودو تطبيق ويب، والوحدات المخصّصة قد تُدخل المخاطر نفسها التي يُدخلها أي كود آخر، خصوصاً أخطاء التحكم في الوصول والمكوّنات القديمة. وينشر أودو إصلاحات أمنية لإصداراته المدعومة، لذلك تأتي معظم المشكلات من التخصيصات والتحديثات الفائتة وإعدادات الخادم.
هل تكفي أداة فحص الثغرات لتغطية Top 10؟
تساعد أداة الفحص في كشف المكوّنات القديمة والإعدادات وبعض ثغرات الحقن، لكنها لا تستطيع الحكم على قواعد الوصول أو منطق العمل، وهناك تقع كثير من المشكلات الخطيرة، لذلك تحتاج أيضاً إلى مراجعة يدوية.
كم مرة تُحدَّث قائمة OWASP Top 10؟
كل بضع سنوات، وفي المرات الأخيرة كل ثلاث إلى أربع سنوات. وقد صدرت إصداراتها في 2003 و2004 و2007 و2010 و2013 و2017 و2021 و2025.
اعرف أين يقف تطبيقك
إن كان عملك يعتمد على تطبيق ويب أو بوابة أو تطبيق مبني بالذكاء الاصطناعي، فاكتشاف هذه الثغرات قبل المهاجم أرخص بكثير. فخدمة تقييم الكود المكتوب بالذكاء الاصطناعي لدينا تفحص أي تطبيق من حيث الأمان وأفضل الممارسات وقابلية الصيانة والجاهزية للإنتاج، وتنتهي بتقرير مكتوب فيه دليل على كل نتيجة وترتيب واضح للإصلاحات. ونوقّع اتفاقية عدم إفصاح قبل أن نرى الكود، وتبدأ أسعار التقييم من $1,000. ولنتحدث في الأمر، احجز مكالمة مجانية مدتها 30 دقيقة.