Lovable تفحص كل تطبيق قبل نشره وتصلح ثغرات الوصول بنقرتين

بنيتَ التطبيق في أمسية واحدة عبر دردشة مع الذكاء الاصطناعي، ويستخدمه الآن أشخاص حقيقيون، فيصبح سؤال «هل هو آمن أصلًا؟» محرجًا. ردّت Lovable بمنشور من فريق الأمان: ما الذي تفعله المنصة بنفسها، وما الذي تُبرزه، وما الذي تتركه لك. لنستعرض ما هو مفيد فعلًا من ذلك.

ما يعمل دون تدخلك

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

دورة «اكتشاف — إصلاح — إصدار»

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

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

وهناك أدوات أخرى:

• يمكن تشغيل فحص عميق في أي وقت وبالمجان: يستغرق وقتًا أطول لكنه يحفر أعمق. وهو مبني على نظام اختبار خاص بالمنصة، مدرَّب على المشكلات النموذجية في تطبيقات Lovable؛
• خيار «Auto-fix security issues» في إعدادات المشروع يعالج كثيرًا من النتائج تلقائيًا مع رسالتك التالية في الدردشة؛
• التحكم في النشر: يمكنك أنت أو مشرف مساحة العمل منع الإصدار ما دامت هناك نتائج حرجة.

والنقطة الأخيرة هي الأكثر عملية على الأرجح، إذ تحوّل الأمان من نصيحة إلى بوابة إلزامية، كاختبار CI أحمر قبل النشر.

ما عليك فعله رغم ذلك

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

ما لا يوجد في المنشور

هذه رسالة من المورّد، ولا أرقام فيها: لا دقة الماسح، ولا نسبة الإنذارات الكاذبة، ولا عدد النتائج التي يعالجها الإصلاح التلقائي بشكل صحيح. وعبارة «كثير من النتائج» تعني أنها ليست كلها. كما أن الإصلاح التلقائي وكيل يعدّل الكود والسياسات، لذا يستحق أن تمرّ بعينيك على الفروقات (diff) على الأقل، خاصة إن كان في التطبيق مدفوعات أو بيانات شخصية. وفي المنتج الجاد، لا يغني الفحص الآلي في رأيي عن تدقيق مستقل.

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

ما العمل إذن

إذا كنت تبني منتجًا على Lovable:

1. فعّل حظر النشر عند وجود نتائج حرجة، وفي المشروع الجماعي اطلب من المشرف فعل الشيء نفسه.
2. فعّل الإصلاح التلقائي، لكن راجع التغييرات في الأماكن التي تُخزَّن فيها بيانات الآخرين.
3. قبل أول إطلاق علني، شغّل الفحص العميق يدويًا.
4. أعد النظر في النتائج «المقصودة»: إن كانت البيانات مفتوحة عن وعي، فوثّق هذا القرار.

وإذا كنت تعمل بأداة «ترميز بالحدس» أخرى، فالسؤال نفسه: هل تفحص سياسات RLS والأسرار قبل الإصدار، وهل تستطيع إيقاف النشر؟ وإن لم تفعل، فسيتعين عليك اجتياز قائمة التحقق هذه يدويًا.