أمان التطبيقات المبنية بالذكاء الاصطناعي: قائمة فحص قبل الإطلاق

قبل أن تُدخلوا بيانات عملاء أو موظفين حقيقية إلى تطبيق بنيتموه بأداة مثل Lovable أو Bolt أو Replit أو Cursor، اختبروه كما يفعل شخص من الخارج. سجّلوا الدخول بحسابين تجريبيين مختلفين، وافتحوا أدوات المطوّر في المتصفح، وحاولوا قراءة سجلات الحساب الآخر. هذا الاختبار وحده يغطي أهم جزء في أمان التطبيقات المبنية بالذكاء الاصطناعي (ما يُعرف بـ vibe coding): من يرى ماذا، ومن يستطيع أن يغيّره. أداة الذكاء الاصطناعي كتبت كوداً يعمل في العرض التجريبي، لكنكم وحدكم تعرفون من يحق له رؤية كل سجل، والاختبار وحده يبيّن أن الكود يطبّق ذلك. راجعوا القائمة التالية قبل الإطلاق، وابدأوا بالصلاحيات، وقرّروا مبكراً هل يستحق الكود الإصلاح أصلاً.

مثالان توضيحيان: مجموعة عيادات خاصة في عمّان تبني تطبيق حجز على Lovable وSupabase، ليحجز المرضى مواعيدهم ويطّلعوا على نتائج تحاليلهم. وفي دبي، يبني مسؤول العمليات في شركة لوجستية أداة داخلية بـ Cursor ترسل تقارير حوادث السائقين إلى نموذج ذكاء اصطناعي لتلخيصها، وتحفظ سجلات إجازات الموظفين. وكلا التطبيقين قد يسبّب ضرراً حقيقياً إذا استطاع مستخدم أن يقرأ بيانات غيره.

القائمة باختصار:

• الوصول: كل طلب يتحقق من دور المستخدم على الخادم.
• المفاتيح السرية: لا مفتاح سري لقاعدة البيانات أو للدفع أو لمزوّد الذكاء الاصطناعي في الكود الذي يصل إلى المتصفح.
• قواعد الوصول إلى الجداول: تشغيل Row Level Security على كل جدول مكشوف، مع اختبار السياسات لكل دور.
• المدخلات والذكاء الاصطناعي: التحقق من المدخلات على الخادم، ومعاملة ردود النموذج على أنها غير موثوقة.
• التشغيل: فحص المكتبات الخارجية، وتسجيل الأحداث الأمنية، واسترجاع نسخة احتياطية مرة واحدة على سبيل التجربة.
• العربية: الاتجاه من اليمين إلى اليسار، وعرض النص المختلط بالعربية والإنجليزية، والبحث بالعربية.

1. من يستطيع تسجيل الدخول، وماذا يرى كل دور؟

ننصح بالبدء هنا لأن خطأً واحداً في الصلاحيات قد يكشف سجلات كل المستخدمين دفعة واحدة. فقائمة OWASP Top 10:2025 تضع ضعف التحكم في الوصول (Broken Access Control) في المرتبة الأولى A01، وأخطاء التحقق من الهوية (Authentication Failures) في المرتبة A07. قد تبني أداة الذكاء الاصطناعي شاشة دخول تعمل خلال دقائق، وتترك الصلاحيات ناقصة، أي القاعدة التي تحدد السجلات التي يحق لكل مستخدم أن يقرأها أو يعدّلها.

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

في مثال العيادات، يرى المريض مواعيده ونتائجه فقط، ويرى موظف الاستقبال حجوزات اليوم دون نتائج التحاليل. وإذا كان التطبيق يحفظ سجلات صحية أو مالية أو بيانات موظفين، فقد تنطبق عليه أيضاً قواعد حماية البيانات وقواعد القطاع، ويتوقف ذلك على الدولة والقطاع، وفي الإمارات على ما إذا كنتم تعملون في منطقة حرة لها قانونها الخاص مثل DIFC أو ADGM. هذه معلومات عامة وليست استشارة قانونية، والالتزامات تتوقف على قطاعكم ونوع البيانات التي تحفظونها.

2. هل توجد مفاتيح سرية في الكود الذي يصل إلى المستخدم؟

كل ما في واجهة التطبيق يصل إلى متصفح المستخدم، ويستطيع أي شخص قراءته بأدوات المطوّر. إذا كان مشروعكم يستخدم Vite (راجعوا ملف package.json)، فإن وثائق Vite عن متغيرات البيئة تذكر أن المتغيرات التي تبدأ بـ VITE_ تظهر في الكود الذي يصل إلى المتصفح بعد تجهيز التطبيق للنشر، وأنها لا ينبغي أن تتضمن مفاتيح API. والأمر نفسه ينطبق على أي مفتاح لصقه مساعد الذكاء الاصطناعي مباشرة داخل الكود.

• ابحثوا في ملفات النسخة النهائية وفي تبويب Network في المتصفح عن مفاتيح مزوّد الذكاء الاصطناعي ومفاتيح الدفع ومفاتيح خدمة البريد والمفتاح السري في Supabase (service_role).
• مفتاح Supabase المخصص للمتصفح (publishable أو anon) مصمَّم ليظهر في الواجهة، لكن أمانه يتوقف على سياسات RLS التي نشرحها في القسم التالي.
• انقلوا كل مفتاح آخر إلى دالة تعمل على الخادم، وغيّروا أي مفتاح ظهر يوماً في المتصفح أو في سجل مستودع الكود (repository)، وتأكدوا أن ملفات .env غير محفوظة في المستودع.

3. هل تسمح سياسات RLS في Supabase لكل مستخدم برؤية الصفوف المسموح له بها فقط؟

عندما يتصل المتصفح بـ Supabase مباشرة، تصبح سياسات الوصول على مستوى الصف (Row Level Security أو RLS) هي طبقة الصلاحيات في تطبيقكم. ويحذّر دليل Supabase عن Row Level Security من أن الجدول المكشوف دون RLS يستطيع قراءته والكتابة فيه أي دور مُنح صلاحية عليه، ويطلب تشغيل RLS على كل جدول من هذا النوع. وبعد تشغيل RLS لا يعيد المفتاح المخصص للمتصفح أي بيانات حتى تضيفوا سياسات. وتذكر وثائق Lovable أن Lovable تستطيع استخدام مشروع Supabase تملكونه واجهةً خلفية (backend) للتطبيق، وأن واجهتها الخلفية المدمجة Lovable Cloud مبنية على أساس Supabase مفتوح المصدر، لذلك ينطبق هذا القسم على تطبيقات Lovable في الحالتين.

• اعرضوا كل الجداول في المخططات (schemas) المكشوفة، وتأكدوا أن RLS يعمل على كل جدول.
• اقرأوا كل سياسة بجملة بسيطة، مثل: "يقرأ المريض الصفوف التي يساوي فيها patient_id رقم حسابه". إذا لم تستطيعوا قولها ببساطة، فأعيدوا كتابتها.
• ابحثوا عن سياسات شرطها صحيح دائماً. تنبّه Supabase إلى أن سياسة كهذه للمستخدمين غير المسجلين تتيح لكل زائر قراءة كل الصفوف. أبقوها للبيانات العامة فقط، مثل قائمة فروع العيادات.
• افحصوا سياسات الإضافة والتعديل لا سياسات القراءة وحدها. المستخدم الذي يعدّل ملفه الشخصي يجب ألا يستطيع تغيير صاحب السجل أو عمود الدور.
• افحصوا تخزين الملفات أيضاً: تقارير التحاليل أو صور الهويات المرفوعة تحتاج القواعد نفسها لكل مستخدم.
• اختبروا بحسابين لكل دور، ثم دون تسجيل دخول، باستخدام المفتاح المخصص للمتصفح وحده. وأبقوا المفتاح السري، الذي يتجاوز RLS، على الخادم.

4. هل يتحقق الخادم من كل مدخل، بما فيه ما يصل إلى نموذج الذكاء الاصطناعي؟

الفحص في المتصفح يساعد المستخدم حسن النية، ويجب أن يكرره الخادم. تحققوا من نوع كل حقل وطوله وصيغته، وحدّدوا نوع الملفات المرفوعة وحجمها، ونظّفوا النص المنسّق (الذي يحتوي تنسيقاً أو روابط) قبل عرضه على مستخدم آخر. وضعوا حداً لعدد المحاولات في تسجيل الدخول وإنشاء الحساب وفي أي استمارة ترسل بريداً أو تستدعي نموذج ذكاء اصطناعي.

إذا كان التطبيق يستدعي نموذجاً لغوياً كبيراً

تضع قائمة OWASP Top 10 for LLM Applications 2025 حقن التعليمات (Prompt Injection) في المرتبة الأولى LLM01. في مثال دبي، قد يحتوي تقرير سائق على نص مكتوب لتوجيه النموذج. لا يمكن تصفية كل رسالة من هذا النوع، لذلك قلّلوا ما يستطيع النموذج فعله إذا نجح أحد في التلاعب به.

• استدعوا النموذج من الخادم، لا من المتصفح.
• لا تضعوا مفاتيح أو قواعد داخلية في تعليمات النظام (system prompt)، فقائمة OWASP تذكر تسرّب تعليمات النظام في المرتبة LLM07.
• عاملوا ردود النموذج على أنها غير موثوقة: حوّلوا رموزها الخاصة إلى نص عادي (escape) قبل عرضها، ولا تشغّلوها أبداً على أنها كود أو استعلام في قاعدة البيانات (LLM05، سوء التعامل مع ردود النموذج).
• أعطوا النموذج البيانات والأدوات التي يحق للمستخدم الحالي رؤيتها فقط. وإذا كان يستطيع إرسال بريد أو تعديل سجلات، فاشترطوا التأكيد البشري (LLM06، الوكالة المفرطة). يشرح مقالنا عن حوكمة وكلاء الذكاء الاصطناعي هذه الحدود.
• ضعوا حداً لعدد الطلبات لكل مستخدم، وحداً للإنفاق لدى مزوّد الذكاء الاصطناعي إن كان يتيحه (LLM10، الاستهلاك غير المحدود).
• اختبروا بمدخلات خبيثة بالعربية والإنجليزية وبنص يخلط اللغتين. ويشرح دليلنا عن تقييم النماذج اللغوية الكبيرة بالعربية طريقة بناء مجموعة اختبار باللهجات التي يكتب بها مستخدموكم.

5. المكتبات والسجلات والنسخ الاحتياطية والعربية: فحوص التشغيل

المكتبات الخارجية

شغّلوا فحص الثغرات الذي يوفره مدير الحزم لديكم، واحذفوا الحزم التي لا يستخدمها التطبيق، وتأكدوا أن كل حزمة أضافها مساعد الذكاء الاصطناعي هي الحزمة المقصودة باسمها الدقيق. وتضع OWASP أخطاء سلسلة توريد البرمجيات (Software Supply Chain Failures) في المرتبة A03:2025. وتذكر وثائق الأمان في Lovable أن الفحص السريع (Quick scan)، الذي يفحص قواعد الوصول إلى قاعدة البيانات والمكتبات وانكشاف خوادم MCP، يعمل تلقائياً عند كل نشر، أما الفحص المعمّق (Deep scan) لكود التطبيق فتشغّلونه عند الحاجة، ويمكن جدولته في خطط Enterprise. وتقول Lovable أيضاً إن هذه الأدوات لا تغني عن مراجعة أمنية شاملة.

سجلات الأحداث

سجّلوا عمليات الدخول والمحاولات الفاشلة وتغيير الأدوار وتصدير البيانات وإجراءات المسؤولين، وأرسلوا التنبيهات إلى شخص محدد بالاسم. ولا تحفظوا كلمات المرور أو رموز الدخول أو الملفات الصحية الكاملة في سجلات الأحداث. وتضع OWASP أخطاء تسجيل الأحداث الأمنية والتنبيه في المرتبة A09:2025.

النسخ الاحتياطية

تذكر وثائق Supabase عن النسخ الاحتياطية أن Supabase تنسخ مشاريع خطط Pro وTeam وEnterprise يومياً، وتنصح مشاريع الخطة المجانية بتصدير بياناتها بانتظام. وأياً كانت خطتكم، استرجعوا نسخة احتياطية واحدة في مشروع تجريبي قبل الإطلاق، وقيسوا الوقت الذي يستغرقه ذلك.

أساسيات العربية والاتجاه من اليمين إلى اليسار

• الصفحات العربية تحمل lang="ar" وdir="rtl"، والأسهم وخطوات التقدم معكوسة الاتجاه.
• النص المختلط، مثل اسم منتج بالإنجليزية أو رقم هاتف أو رقم حجز داخل جملة عربية، يظهر بالترتيب الصحيح.
• البحث يجد الكلمة العربية سواء كُتبت بالهمزة أو بدونها، وبالتاء المربوطة أو بالهاء.
• الرسائل البريدية وملفات PDF ورسائل الخطأ تعرض النص العربي سليماً، ولا تكشف أي رسالة خطأ تفاصيل النظام الداخلية.

الإصلاح أم إعادة الهيكلة أم إعادة البناء: كيف تقرّرون؟

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

وأياً كان قراركم، أضيفوا اختبارات آلية لقواعد الوصول، حتى لا يلغيها تعديل لاحق يكتبه الذكاء الاصطناعي دون أن ينتبه أحد.

كيف تبدأون فحص أمان التطبيقات المبنية بالذكاء الاصطناعي؟

أجروا اختبار الحسابين هذا الأسبوع، فهو أول خطوة في أمان التطبيقات المبنية بالذكاء الاصطناعي، ثم راجعوا بقية القائمة بالترتيب. وإذا أردتم مراجعة ثانية، فخدمة مراجعة جاهزية التطبيقات المبنية بالذكاء الاصطناعي تدقّق التطبيقات المبنية بـ Lovable أو Bolt أو Replit أو Cursor، ثم تصلحها أو تعيد هيكلتها أو تعيد بناءها مع أتمتة الاختبارات. واطّلعوا على صفحة التطبيق المبني بالذكاء الاصطناعي وصفحة مختبر التحوّل. وإذا لم تكونوا متأكدين من نقطة البداية، فخدمة مسح واقع الذكاء الاصطناعي في شركتكم المجانية محادثة مدتها 45 دقيقة تنتهي بخطوة تالية مكتوبة.

المختبر المرتبط: مختبر التحوّل ↖