هل تطبيقات البرمجة بالإيحاء آمنة؟ 8 ثغرات يجب فحصها

هل التطبيقات المبنية بالبرمجة بالإيحاء آمنة؟

ليس افتراضيًا: وجدت كل الدراسات الكبيرة المذكورة هنا ثغرات أمنية خطيرة في نسبة كبيرة من التطبيقات التي فحصتها ^[3][4][5]. التطبيقات تعمل في الغالب. المشكلة فيما تسمح به للغرباء.

جمع تدقيق أُجري في 2026 نحو 9,041 تطبيقًا مفتوح المصدر بُنيت باستخدام Claude Code وLovable، وفحص 200 منها منشورة للعامة. وعثر على 1,186 ثغرة، وكان في 182 من أصل 200 تطبيق (91.0%) ثغرة واحدة على الأقل ^[4]. وصُنّفت 65.77% من هذه الثغرات حرجة أو عالية الخطورة، منها 18.47% حرجة ^[4].

واختبر الباحثون أيضًا ما إذا كانت الأوامر النصية الأفضل وإعدادات الوكلاء المحسّنة تحل المشكلة. فقد خفّفتها لكنها لم تُزلها، والمهمة نفسها حين تُنفّذ ثلاث مرات قد تعطي نتيجة آمنة مرة وغير آمنة في المرة التالية ^[4]. أي أن نتيجة نظيفة في إصدار واحد لا تقول الكثير عن الإصدار التالي.

لأساسيات هذه الطريقة راجع دليل Pouyam بعنوان Vibe Coding Explained: What It Is, How It Works and the Real Risks (شرح البرمجة بالإيحاء ومخاطرها الحقيقية). ولأول مشروع يقدّم دليل Vibe Coding for Beginners: How to Start Safely in 2026 (البرمجة بالإيحاء للمبتدئين) خطة للبدء. أما هذه الصفحة فتنزل مستوى أعمق: الثغرات المحددة وطريقة فحص كل منها.

ماذا تجد الدراسات الأمنية في تطبيقات البرمجة بالإيحاء؟

تشير أربعة مصادر مستقلة إلى نقطة الضعف نفسها: بيانات يستطيع الشخص الخطأ قراءتها أو تغييرها ^[1][3][4][5].

• تدقيق 200 تطبيق منشور (2026): كان خلل التحكم بالوصول أكبر فئة، بواقع 339 من أصل 1,186 ثغرة (28.58%)، وأصاب 64.00% من التطبيقات. وأصاب الحقن 54.00% منها، وإخفاقات المصادقة 51.50% ^[4].
• دراسة ACM CCS لعام 2026: في 8,641 مستودعًا على Lovable بسجل كامل، كانت 11.2% من قواعد القراءة مفتوحة للزوار غير المسجّلين، وكان في 61.2% من المستودعات قاعدة واحدة على الأقل من هذا النوع. وأكّد اختبار إعادة التشغيل الانكشاف في 353 من أصل 400 مستودع في العينة ^[5].
• Escape (أكتوبر 2025): وجد فحص سلبي لأكثر من 5,600 تطبيق عام مبني على منصات مثل Lovable وBase44 وCreate.xyz أكثر من 2,000 ثغرة وأكثر من 400 سرّ مكشوف و175 حالة بيانات شخصية، منها سجلات طبية وأرقام IBAN (معرّفات الحسابات المصرفية) وأرقام هواتف وعناوين بريد إلكتروني ^[3].
• CVE-2025-48757 (2025): وجد فحص اكتمل في 21 مارس 2025 نحو 303 نقاط وصول إلى قواعد بيانات في 170 من أصل 1,645 مشروعًا على Lovable، أي نحو 10.3%، بقواعد صفوف غير كافية ^[1].

تؤكد Escape أن فحصها تجنّب أي إجراء مدمّر، ولذلك فأرقامها حد أدنى، وأن فحصًا أعمق سيجد المزيد ^[3]. والحذر نفسه ينطبق على كل الأرقام هنا: هذه الدراسات تحصي ما أمكنها رؤيته من الخارج.

لماذا تبني أدوات الذكاء الاصطناعي تطبيقات غير آمنة؟

لأن الأدوات تسعى إلى تطبيق يعمل، بينما تعتمد قواعد الأمان على تفاصيل عمل نادرًا ما يذكرها الأمر النصي ^[4][11].

من السهل التحقق من شيفرة تعمل: الصفحة تُحمَّل والزر يستجيب. أما من يحق له رؤية كل سجل فهو قرار عمل، وإذا لم يكتبه أحد فعلى الأداة أن تخمّن. ويرجع تدقيق 2026 الثغرات إلى ثمانية أنماط إخفاق متكررة، مجمّعة في ثلاثة حدود لوكلاء الذكاء الاصطناعي: الذاكرة والأهداف والمعرفة ^[4].

وتُظهر الاختبارات الواسعة لنماذج الذكاء الاصطناعي الفجوة نفسها. فقد وجد تقرير GenAI Code Security Report 2026 من Veracode أن نحو 44% من مهام توليد الشيفرة أدخلت ثغرة أمنية في اختباراته ^[11]. ووجد اختبار معياري استشهدت به AWS أن أفضل إعداد من بين 12 إعدادًا للوكلاء حلّ 57% من المهام بشكل صحيح، لكنه حلّ 11.8% فقط بشكل صحيح وآمن معًا ^[10].

كما أن كثيرًا من تطبيقات البرمجة بالإيحاء ينقل عبء الأمان إلى قاعدة البيانات. فالمتصفح يتصل مباشرة بقاعدة بيانات مستضافة، فتصبح قواعدها الحاجز الوحيد بين الزائر وكل صف ^[1][6]. وإذا غابت القواعد أو كانت واسعة جدًا، يستطيع أي شخص يعرف العنوان أن يطلب كل شيء.

ما الثغرات الأمنية الـ8 التي يجب فحصها أولًا؟

ابدأ بالثغرات التي تجدها الدراسات أكثر من غيرها، مرتّبة حسب حجم الضرر المحتمل ^[1][3][4][5].

1. قواعد قاعدة بيانات مفتوحة: جداول بلا أمان على مستوى الصفوف، أو بقواعد تسمح لأي زائر بقراءة كل الصفوف. وكان هذا أصل الثغرة CVE-2025-48757 ونتائج دراسة ACM ^[1][5].
2. خلل التحكم بالوصول: مستخدم مسجّل يفتح سجل مستخدم آخر بتغيير معرّف في العنوان أو الطلب. وكان أكبر فئة في تدقيق 2026 ^[4].
3. مفاتيح سرية في المتصفح: مفتاح secret أو service_role من Supabase، أو مفتاح دفع، أو مفتاح مزوّد ذكاء اصطناعي موضوع في شيفرة الواجهة. وجدت Escape أكثر من 400 سرّ مكشوف ^[3][6].
4. غياب التحقق من الدخول أو ضعفه: صفحات خاصة أو مسارات واجهة برمجية تستجيب دون جلسة. أصابت إخفاقات المصادقة 51.50% من التطبيقات المدقّقة ^[4].
5. الحقن: مدخلات المستخدم تصل إلى استعلامات قاعدة البيانات أو إلى HTML دون فحص، ووُجد في 54.00% من التطبيقات المدقّقة ^[4].
6. جداول قابلة للكتابة: قواعد تسمح للزوار بإدخال البيانات أو تغييرها، لا بقراءتها فقط. وفي حالة الثغرة، أدخل طلب بلا رمز دخول سجلًا مُعلَّمًا بأنه "مدفوع" متجاوزًا خطوة الدفع ^[1].
7. استجابات تكشف أكثر من اللازم: واجهات برمجية تعيد سجلات مستخدمين كاملة أو عناوين بريد أو رموزًا بينما تحتاج الصفحة إلى اسم فقط. أحصت Escape نحو 175 حالة بيانات شخصية مكشوفة ^[3].
8. وصول خطر للوكلاء: وكيل برمجة يملك بيانات اعتماد بيئة الإنتاج قد يسبب ضررًا حقيقيًا؛ ففي يوليو 2025 حذف وكيل قاعدة بيانات حيّة أثناء تجميد الشيفرة ^[10].

تغطي الثغرات من 1 إلى 4 معظم ما يستغله المهاجمون من الخارج، لذا افحصها قبل أي شيء آخر.

كيف أفحص تطبيقي المبني بالبرمجة بالإيحاء بحثًا عن هذه الثغرات؟

استخدم التطبيق كما يفعل المهاجم: كغريب، وكمستخدم ثانٍ، وبقراءة ما يتلقاه المتصفح ^[1][4][5]. لا تحتاج أي خطوة إلى أدوات خاصة.

1. أنشئ حسابين تجريبيين. أنشئ سجلًا بالحساب الأول، وانسخ عنوانه أو معرّفه، ثم ادخل بالحساب الثاني وحاول فتحه وتعديله وحذفه. إذا نجح ذلك فالتحكم بالوصول معطّل ^[4].
2. كرّر الخطوة دون تسجيل دخول. افتح العناوين نفسها في نافذة خاصة بلا جلسة. ففي حالة الثغرة كان حذف ترويسة الدخول كافيًا لتجاوز كل الفحوص ^[1].
3. راقب تبويب الشبكة. في أدوات المطوّر في المتصفح، اطّلع على كل طلب ترسله الصفحة وعلى ما يعود منه. يجب أن تحتوي الاستجابات على ما تحتاجه تلك الشاشة فقط، لا على بريد أو رموز مستخدمين آخرين ^[3].
4. ابحث عن المفاتيح في شيفرة الصفحة. ابحث عن نصوص تبدأ بـ sb_secret_ أو عن كلمة service_role أو عن مفاتيح مزوّدين مثل الدفع أو الذكاء الاصطناعي. وجود مفتاح publishable أمر متوقع، أما مفتاح secret فحالة طوارئ ^[6].
5. افحص قواعد كل جدول. في لوحة قاعدة البيانات تأكّد أن الأمان على مستوى الصفوف مفعّل لكل جدول، واقرأ كل قاعدة بلغة بسيطة: من يقرأ ومن يكتب ^[7].
6. جرّب مدخلات غير مألوفة. الصق نصوصًا طويلة جدًا وعلامات اقتباس ووسوم HTML في كل نموذج، وانظر هل يتعطل التطبيق أو يعرضها كشيفرة ^[4].

افحص فقط التطبيقات التي تملكها أو التي لديك إذن بفحصها. ولا تتنقّل في تطبيقات الآخرين بحثًا عن ثغرات دون إذن كتابي.

كيف أصلح قواعد Supabase المفتوحة والمفاتيح المسرّبة؟

فعّل الأمان على مستوى الصفوف لكل جدول، واكتب قواعد ضيقة، واحفظ المفاتيح السرية على الخادم، واستبدل أي مفتاح مسرّب ^[6][7][8].

• فعّل الأمان على مستوى الصفوف في كل مكان. يقول دليل Supabase بتفعيله على كل جدول في مخطط معرّض للوصول ^[7]. وبعد تفعيله لا يصل المفتاح العام إلى أي شيء حتى تضيف القواعد ^[7].
• أزل الصلاحيات الافتراضية. في المشاريع التي ما زالت تمنحها افتراضيًا، يبدأ أي جدول عام جديد وقد مُنحت كل الامتيازات لدوري غير المسجّلين (anon) والمسجّلين (authenticated)، وإضافة القواعد لا تسحب هذه الصلاحيات ^[7]. اسحبها وامنح كل دور ما يحتاجه فقط ^[7].
• اكتب قواعد لكل مستخدم. يجب أن تطابق قاعدة الجدول الخاص معرّف المستخدم المسجّل، لا أن تسمح لكل من سجّل الدخول. وتجنّب القواعد الصحيحة دائمًا على الجداول الحساسة ^[2].
• احفظ المفاتيح السرية على الخادم. مفتاح publishable في Supabase آمن في المتصفح فقط لأن قواعد الصفوف تقيّده؛ أما مفتاحا secret وservice_role فيتجاوزان كل القواعد ويجب أن يبقيا في شيفرة الخادم أو في إعدادات بيئة آمنة ^[6].
• بدّل المفاتيح المسرّبة. إذا وصل مفتاح سري يومًا إلى المتصفح أو إلى مستودع شيفرة عام، فبدّله وعطّل المفتاح المسرّب، كما يوصي دليل المفاتيح في Supabase ^[6].

اعتبارًا من 15 نوفمبر 2026، تقول وثائق Supabase إنها ستُلغي مفاتيح anon وservice_role القديمة بحلول نهاية 2026 لصالح مفاتيح publishable وsecret ^[8]. والمفاتيح السرية الجديدة تُرجع خطأ (HTTP 401) عند استخدامها في المتصفح، مع أن المفتاح المسرّب يمكن استخدامه من أدوات أخرى ^[6][8]. والانتقال الآن فرصة جيدة لمراجعة كل مفتاح يستخدمه التطبيق.

هل تكشف أدوات الفحص الأمني المدمجة كل شيء؟

لا: أدوات الفحص في المنصات مفيدة، لكن عدة دراسات تُظهر أنها تفوّت أهم القواعد ^[1][2][5].

في 2025 وجد الباحثون الذين كشفوا الثغرة CVE-2025-48757 أن أداة الفحص في Lovable كانت تتحقق فقط من وجود قاعدة صفوف، لا من صحتها ^[1]. ويضيف إشعارهم أن فحص النشر في Lovable ينبّه إلى الجداول التي بلا قواعد، لكنه لا يبيّن هل القواعد صارمة بما يكفي ^[2]. والقاعدة المفتوحة تجتاز فحصًا كهذا.

وتثبت دراسة ACM ذلك بالأرقام: نسبة متواضعة من القواعد المفتوحة، 6.3% عبر ست أدوات، تركت مع ذلك 56.9% من المستودعات بجدول مكشوف واحد على الأقل، لأن قاعدة مفتوحة واحدة تكفي ^[5]. وأصدر الباحثون أداة فحص مجانية تنبّه إلى هذه القواعد قبل حفظ الشيفرة ^[5].

استخدم أدوات الفحص كمرشّح أول، ثم أجرِ بنفسك اختبار الحسابين واختبار عدم تسجيل الدخول. ويلخّص الجدول أدناه الأرقام.

هل من الآمن استخدام تطبيقات بناها آخرون بالبرمجة بالإيحاء؟

كن حذرًا مع أي تطبيق يطلب بيانات شخصية أو صحية أو بيانات دفع، لأن المستخدمين لا يرون كيف يحميها التطبيق ^[3][4]. وجدت Escape بين البيانات المكشوفة سجلات طبية وأرقام IBAN (معرّفات الحسابات المصرفية) ^[3].

بعض العادات البسيطة تقلّل الخطر. استخدم كلمة مرور مختلفة لكل تطبيق جديد حتى لا يفتح تسريب في أحدها حسابات أخرى؛ ويشرح دليل Pouyam بعنوان Password Managers Explained: How They Work and Whether They Are Safe (شرح مديري كلمات المرور) طريقة ذلك. شارك الحد الأدنى من البيانات التي يحتاجها التطبيق، وفضّل صفحات الدفع التابعة لمزوّدي دفع معروفين على النماذج داخل التطبيق.

تقع المسؤولية الأساسية على صانعي التطبيقات. إذا نشرت تطبيقًا يخزّن بيانات الآخرين، فأجرِ الفحوص السابقة قبل الإطلاق وبعد كل تغيير كبير، لأن ميزة جديدة واحدة قد تعيد فتح ثغرة مغلقة ^[4][5].