يمكن لأدوات بناء التطبيقات بالذكاء الاصطناعي مثل Lovable وBolt وReplit وv0 وCursor أن تنقلك من فكرة إلى عرض تجريبي يعمل في غضون أيام. هذا إنجاز حقيقي، وهو أيضاً النقطة التي تبدأ عندها المخاطر. فالعرض التجريبي له مستخدم واحد وبيانات اختبارية ولا تترتب عليه أي عواقب. أما التطبيق الإنتاجي فله مستخدمون غرباء وبيانات شخصية ومدفوعات وسمعة يجب حمايتها.
تغطي قائمة التحقق هذه 20 أمراً يفحصها المهندس قبل وصول المستخدمين الحقيقيين. وقد كُتبت للمؤسسين وأصحاب المنتجات، لذا تشرح كل نقطة سبب أهميتها وكيفية التحقق منها دون قراءة قاعدة الشيفرة بأكملها. وإذا لم تستطع الإجابة بثقة عن أكثر من بضع نقاط منها، فإن التدقيق التقني لتطبيقات الذكاء الاصطناعي سيخبرك بموقعك الحقيقي قبل أن يفعل ذلك يوم الإطلاق.
كيف تستخدم قائمة التحقق هذه
اعمل على المجموعات الخمس أدناه وضع على كل نقطة علامة تم التحقق (اختبرتها أنت أو شخص آخر)، أو مفترض (غالباً أنجزها المطوّر)، أو غير معروف. تعامل مع «مفترض» كما تتعامل مع «غير معروف». فأدوات الذكاء الاصطناعي تنتج شيفرة تبدو مكتملة، وتميل الثغرات إلى الظهور تحديداً حيث لم يختبر أحد.
1. الحسابات والوصول
- التسجيل والتحقق من البريد الإلكتروني وإعادة تعيين كلمة المرور تعمل من البداية إلى النهاية. أنشئ حساباً جديداً تماماً، وتحقق منه، وأعد تعيين كلمة المرور، ثم حاول إعادة استخدام رابط إعادة التعيين القديم. يجب أن تنتهي صلاحية روابط إعادة التعيين وألا تعمل إلا مرة واحدة.
- الصلاحيات تُفرض على الخادم، وليس بمجرد إخفائها في الواجهة. الزر المخفي عن المستخدمين العاديين لا يحمي شيئاً إذا كان الطلب الأساسي لا يزال يعمل. سجّل الدخول كمستخدم عادي واستدعِ نقاط نهاية الإدارة مباشرة. يجب أن ترفضها.
- الأدوار مخزّنة في مكان لا يستطيع المستخدمون تعديله. في بعض البنى التقنية يمكن للمستخدم تغيير البيانات الوصفية لملفه الشخصي. فإذا كان الحقل "is_admin" موجوداً هناك، يستطيع أي مستخدم ترقية نفسه. مكان الأدوار هو جدول محمي أو مطالبات (claims) يتحكم بها الخادم.
- تسجيل الدخول ونقاط النهاية الحساسة الأخرى مقيّدة بمعدل الطلبات. دون هذه الحدود يستطيع المهاجمون تجربة آلاف كلمات المرور أو الرموز لمرة واحدة، وتستطيع الروبوتات ملء نموذج التسجيل لديك.
- مناطق الإدارة محمية وحسابات المسؤولين تستخدم المصادقة متعددة العوامل. يجب ألا تكفي كلمة مرور مسؤول واحدة مسروقة لقراءة بيانات كل العملاء.
2. البيانات والخصوصية
- كل جدول يحتوي على بيانات المستخدمين له قواعد وصول. مع Supabase يعني هذا Row Level Security. الجدول الذي لا يملكها يمكن لأي شخص يملك مفتاح API العام الخاص بك قراءته. اطلع على دليلنا حول أخطاء RLS السبعة التي ترتكبها التطبيقات المبنية بالذكاء الاصطناعي.
- عزل المستأجرين (tenants) يُثبَت بحسابَي اختبار. سجّل الدخول كالعميل A، وانسخ معرّف سجل، ثم حاول فتحه أو تعديله كالعميل B. جرّب أيضاً تغيير المعرّفات في الروابط واستدعاءات API. هذا هو الاختبار الأعلى قيمة لأي منتج متعدد المستخدمين.
- تغييرات قاعدة البيانات موجودة في عمليات ترحيل (migrations) خاضعة للتحكم في الإصدارات. إذا كان المخطط موجوداً فقط داخل لوحة تحكم أداة البناء، فلن تستطيع إعادة إنشائه أو مراجعته أو التراجع عنه. تذكّر أن بعض التغييرات، مثل حذف عمود، لا يمكن التراجع عنها دون نسخة احتياطية.
- النسخ الاحتياطية مفعّلة، وقد جُرّبت عملية الاستعادة. النسخة الاحتياطية التي لم تستعدها قط مجرد أمل وليست خطة. قِس المدة التي تستغرقها الاستعادة ودوّنها.
- تعرف ما البيانات الشخصية التي تخزّنها وكيف تحذفها. اذكر الحقول، وأماكن وجودها (بما في ذلك السجلات والأدوات الخارجية)، وما يحدث عندما يطلب مستخدم إزالة بياناته.
3. المدفوعات والاشتراكات
- خطافات الويب (webhooks) الخاصة بالدفع يُتحقق من توقيعها وهي متكررة الأمان (idempotent). وإلا استطاع أي شخص تزوير رسالة «نجحت عملية الدفع»، ويمكن أن يؤدي تكرار التسليم إلى سجلات مكررة. التفاصيل في دليلنا حول خطافات Stripe والاشتراكات.
- الوصول المدفوع يأتي من أحداث الاشتراك وليس من صفحة الشكر. صفحة النجاح ليست سوى إعادة توجيه في المتصفح. يغلق الناس علامات التبويب، ويستطيع أي شخص كتابة العنوان يدوياً.
- وضع الاختبار والوضع الحي منفصلان تماماً، والإخفاقات تُعالَج. مفاتيح ومنتجات ونقاط نهاية خطافات ويب منفصلة. تحقق مما يحدث عند فشل التجديد، والإلغاء، والاسترداد، وتغيير الخطة.
4. الأسرار والتكاملات
- لا أسرار في حزمة الواجهة الأمامية ولا في سجل Git. كل ما يُشحن إلى المتصفح عام. ابحث في JavaScript المبني وفي مستودعك عن مفاتيح الخدمات ورموز API. غيّر (rotate) أي شيء تعرّض يوماً للكشف، لأن حذف الملف لا يحذف السجل.
- مفاتيح الأطراف الثالثة تحمل أقل صلاحيات ممكنة وحدود إنفاق. هذا مهم جداً لميزات الذكاء الاصطناعي. فمفتاح API غير مقيّد لنموذج لغوي في تطبيق عام قد يتسبب في فاتورة ضخمة خلال ساعات. حدّد سقوف الاستخدام وحدوداً لكل مستخدم.
- رفع الملفات ومجموعات التخزين (buckets) مقفلة بإحكام. تحقق ممن يستطيع قراءة كل مجموعة، ومن يستطيع الرفع، وهل نوع الملف وحجمه محدودان. المجموعات العامة مناسبة للصور العامة وخطيرة للفواتير أو وثائق الهوية.
5. النشر والعمليات
- بيئة الاختبار (staging) والإنتاج منفصلتان. قواعد بيانات مختلفة، ومفاتيح مختلفة، ونطاقات مختلفة. الاختبار على بيانات الإنتاج هو السبب في تلقي العملاء رسائل بريد إلكتروني تجريبية.
- مراقبة الأخطاء وتنبيهات التوفر تصل إلى شخص سيتصرف. إذا كان أول ما تعلم به عن انقطاع الخدمة رسالة من عميل، فالمراقبة مفقودة.
- النطاق وHTTPS وقابلية تسليم البريد الإلكتروني مهيّأة بشكل صحيح. ويشمل ذلك سجلات SPF وDKIM وDMARC، حتى لا تصل رسائل التحقق والإيصالات إلى البريد المزعج.
- توجد خطة للتراجع ومالك مسمّى. من يستطيع النشر؟ كيف تعود إلى آخر نسخة تعمل؟ من المناوب عند الطوارئ؟ وبعد الإطلاق يجب أن يطبّق أحدٌ التحديثات، وهذا ما تغطيه الصيانة الشهرية لتطبيقات SaaS.
ماذا تفعل بنتائجك
- معظم النقاط متحقق منها مع بعض المجهولة: اختبر المجهول بنفسك هذا الأسبوع، ثم أطلق مع تفعيل المراقبة.
- عدة نقاط مجهولة في المجموعات من 1 إلى 3: توقف. الوصول والبيانات والمدفوعات هي المواضع التي تتحول فيها الأخطاء إلى حوادث. مراجعة مركّزة لهذه المجالات أرخص من اختراق أو خلل في الفوترة.
- إخفاقات معروفة: دوّنها مع خطوات إعادة إنتاجها. هذه القائمة هي بالضبط ما يحتاجه المهندس لتحديد نطاق الإصلاح، وهي نقطة البداية لعملنا في إصلاح تطبيقات الذكاء الاصطناعي وإطلاقها في بيئة الإنتاج.
ما لا تستطيع قائمة التحقق إخبارك به
تكتشف قائمة التحقق فئات المشكلات المعروفة. لكنها لا تستطيع الحكم على قدرة بنيتك المعمارية على استيعاب النمو، أو على وجود عيوب دقيقة في منطق عملك، أو على إمكانية أن يربط مهاجم نقاط ضعف صغيرة بعضها ببعض. وإذا كنت بحاجة إلى تقييم أمني رسمي، فاطلع على الفرق في مقارنتنا بين التدقيق التقني واختبار الاختراق ومراجعة الشيفرة.
الخبر الجيد أن معظم عوائق الإطلاق في التطبيقات المبنية بالذكاء الاصطناعي قابلة للإصلاح دون إعادة كتابة. والهدف هو اكتشافها بينما لا يتأثر بها أحد سواك.
الأسئلة الشائعة
هل التطبيق المبني بـ Lovable أو Bolt جاهز للإنتاج؟
ليس تلقائيًا. تنتج هذه الأدوات شاشات تعمل بسرعة، لكن التحكم في الوصول وأذونات البيانات والمدفوعات والأسرار والنشر تحتاج عادةً إلى تحقق. تُظهر قائمة التحقق أعلاه ما ينبغي اختباره قبل وصول المستخدمين الحقيقيين.
ما الذي ينبغي فحصه أولًا قبل إطلاق تطبيق مبني بالذكاء الاصطناعي؟
ابدأوا بالوصول والبيانات والمدفوعات: التفويض من جانب الخادم، وعزل المستأجرين المختبر بحسابين، وقواعد الوصول إلى قاعدة البيانات مثل أمان مستوى الصف (Row Level Security)، وWebhooks المدفوعات الموثقة. هذه هي المجالات التي تتحول فيها الأخطاء إلى حوادث.
هل أحتاج إلى تدقيق أمني قبل الإطلاق؟
مراجعة سير العمل الحرجة لديكم مستحسنة بشدة إذا كان التطبيق يتعامل مع بيانات شخصية أو مدفوعات. والتدقيق التقني خطوة أولى عملية؛ أما اختبار الاختراق الرسمي فيأتي عادةً لاحقًا بعد إصلاح الأساسيات.
كيف أختبر أن عميلًا لا يستطيع رؤية بيانات عميل آخر؟
أنشئوا حسابين ببيانات منفصلة، وسجلوا الدخول بالحساب الثاني وحاولوا فتح سجلات الحساب الأول وتعديلها وحذفها بتغيير المعرّفات في الروابط والطلبات. واختبروا كذلك API مباشرة، دون الواجهة.
كيف يمكننا المساعدة
- تدقيق تقني لتطبيقات الذكاء الاصطناعيمراجعة بنطاق ثابت للتطبيقات المبنية بـ Lovable وCursor وBolt وReplit وv0 — المصادقة وSupabase RLS وStripe والأسرار والنشر — مع خطة إصلاح مرتبة حسب الأولوية.
- إصلاح تطبيقات الذكاء الاصطناعي وإطلاقها في الإنتاجإصلاح مشكلات تسجيل الدخول وأذونات Supabase وStripe وAPI والنشر التي تعيق تطبيقكم المبني بالذكاء الاصطناعي، ثم إطلاق نسخة إنتاجية مضبوطة.
- صيانة SaaS الشهريةرعاية شهرية لتطبيقات SaaS والويب — مراقبة ونسخ احتياطية وتحديثات أمنية وإصلاح الأخطاء وفحص التكاملات وإصدارات مضبوطة وتقرير شهري.
تحدثوا إلى مهندس حول مشروعكم
أخبرونا بما تبنونه. نردّ خلال يوم عمل واحد برأي صريح حول النطاق والنهج والجهد المطلوب.
احجزوا مكالمة استراتيجية مجانيةكتبه الفريق الهندسي في UnlockLive IT. تعمل UnlockLive IT Limited مع العملاء عبر مقرها الرئيسي في تورنتو، وتقدم الأعمال الهندسية من مركز التسليم في دكا. من نحن