هل تطبيقك المبني على Lovable آمن؟ قائمة تحقّق Supabase RLS

وصفتَ فكرتك، فأنشأ Lovable تطبيقًا يعمل، ومنحك Supabase بهدوء قاعدة بيانات Postgres حقيقية خلفه. يبدو أن العمل قد اكتمل. لكن هناك ثغرة لا يُغلقها تقريبًا أي تطبيق مبني بأسلوب vibe-coding من تلقاء نفسه: قاعدة البيانات على الأرجح قابلة للقراءة والكتابة من قِبل أي شخص يستطيع الوصول إلى الـ API الخاص بك. هذه ليست علة في Lovable ولا في Supabase — إنها الحالة الافتراضية. تُطلَق التطبيقات المبنية بالذكاء الاصطناعي غير آمنة افتراضيًا: نحو 91.5% منها يحمل ثغرة واحدة على الأقل، وبينما يكون نحو 61% من الشيفرة المولّدة صحيحًا وظيفيًا، فإن حوالي 10.5% فقط يجتاز المراجعة الأمنية. وأكثر ما يوقع مؤسسي Lovable في الفخ هو غياب أو تعطُّل Row-Level Security (RLS). تشرح هذه القائمة لماذا يحدث ذلك، وكيف تتحقق من تطبيقك، وكيف تُصلحه.

لماذا تكون قاعدة البيانات مكشوفة افتراضيًا

يتواصل تطبيق Lovable مع Supabase مباشرةً من المتصفح باستخدام مفتاح anon العام. هذا المفتاح مُصمَّم ليكون عامًا — فهو يُعرّف مشروعك، لا خادمًا موثوقًا. الحارس الحقيقي يُفترض أن يكون Row-Level Security: سياسات في Postgres تُقرّر، صفًا بصف، من يُسمح له برؤية كل سجل أو تعديله. حين تكون RLS مُعطّلة على جدول، أو مُفعّلة بدون أي سياسات (أو بسياسة متساهلة مثل 'using (true)')، يستطيع مفتاح anon عمليًا الاستعلام عن الجدول بأكمله. أي شخص يفتح تبويب الشبكة في تطبيقك يمكنه نسخ هذا المفتاح واستدعاء نقطة نهاية REST في Supabase مباشرةً — بلا تسجيل دخول، وبلا واجهة تطبيق، وبلا حدٍّ لفضوله. ولأن مهمة الذكاء الاصطناعي كانت تشغيل الميزة لا التفكير في من يجب منعه، فإن RLS هي الخطوة التي تُهمَل بصمت. فحصت Escape.tech نحو 5,600 تطبيق مبني بالذكاء الاصطناعي فوجدت 2,038 ثغرة حرجة، وأكثر من 400 سر مكشوف، و175 تسريبًا لبيانات شخصية — وهذه صورة ترك الباب مفتوحًا على نطاق واسع.

كيف تتحقق من تطبيقك في خمس دقائق

لست بحاجة إلى أن تكون مهندس أمن لاكتشاف هذا. افتح لوحة تحكم مشروعك في Supabase وانتقل إلى Table Editor أو إلى Authentication ثم Policies. يُظهر Supabase بوضوح الجداول التي تكون فيها RLS مُعطّلة، ويعرض لك قائمة السياسات على كل جدول. أي جدول يحمل بيانات المستخدمين — الملفات الشخصية، الطلبات، الرسائل، الملفات المرفوعة — تظهر فيه RLS مُعطّلة أو تظهر فيه صفر سياسات، هو عمليًا عام. اختبار ثانٍ أوضح: بينما أنت خارج التطبيق (مسجّل الخروج)، حاول تحميل صفحة أو إطلاق طلب يقرأ بيانات، وراقب هل ما زالت السجلات تعود. إذا استطاع زائر مسجّل الخروج (أو جلسة مستخدم آخر) سحب صفوف يُفترض أن تكون خاصة، فسياساتك لا تؤدي عملها. عامِل كل جدول كأنه مُدان حتى ترى سياساته بعينيك.

قائمة تحقّق RLS: أصلِح وتحقّق

• —فعِّل RLS على كل جدول يحمل بيانات المستخدمين أو الأعمال — لا الجداول الواضحة فقط. جدول واحد منسيّ يكفي لتسريب كل شيء.
• —تأكّد أن لكل جدول سياسات صريحة. RLS مُفعّلة بلا سياسات تمنع الجميع؛ وهذا آمن لكنه معطّل وظيفيًا. وRLS بسياسة 'using (true)' تسمح للجميع؛ وهذا مكشوف. لا تريد أيًّا منهما.
• —قيِّد سياسات القراءة بالملكية: يجب أن يقرأ المستخدم الصفوف التي يطابق فيها عمود المالك هويته المُوثّقة auth.uid()، لا كل الصفوف.
• —اكتب سياسات منفصلة وصريحة للإدراج (insert) والتحديث (update) والحذف (delete) — فصلاحية القراءة ليست صلاحية كتابة. تأكّد أن المستخدم لا يستطيع تعديل أو حذف صفوف لا يملكها.
• —تحقّق من جهة العميل، لا من محرّر SQL فقط. يعمل محرّر SQL بدور إداري يتجاوز RLS، فيبدو كل شيء سليمًا حتى لو كان الـ API العام مكشوفًا بالكامل. اختبر بمستخدم مسجّل دخول عادي وبجلسة مسجّلة الخروج.
• —أبقِ مفتاح service_role على الخادم حصريًا (في edge functions أو خلفية) ولا تضعه أبدًا في حزمة المتصفح؛ مفتاح anon وحده هو ما ينتمي إلى شيفرة العميل.
• —أعد التدقيق بعد كل تعديل يجريه الذكاء الاصطناعي. إعادة توليد ميزة أو إضافة جدول قد تُعيد بصمت جدولًا غير محميّ.
• —افحص أيضًا حاويات التخزين (storage buckets): لدى Supabase Storage قواعد وصول خاصة به، والحاوية العامة تُسرّب الملفات كما يُسرّب الجدول المكشوف الصفوف.

RLS مُفعّلة بلا سياسات آمنة لكنها معطّلة؛ وسياسة 'using (true)' معطّلة وخطيرة. الأمان الحقيقي يعيش في المساحة الضيقة بين الاثنين — وهذه المساحة تُكتَب، لا تُولَّد.

هذه ليست مشكلة Lovable وحدها

لكل أداة إخفاق افتراضي مميّز. إخفاق Lovable هو RLS المعطّلة. وBolt.new يميل إلى تضمين الأسرار داخل حزمة العميل التي تُرسَل إلى المتصفح. وCursor غالبًا يُنتج تفويضًا معطّلًا على مستوى الكائن (BOLA)، حيث يقرأ مستخدمٌ سجلَّ آخر بمجرّد تغيير مُعرّف في الطلب. وعمليات نشر Replit كشفت ملفات .env وأسرارًا بشكل عام. وv0 كثيرًا ما يترك مسارات الـ API بلا مصادقة. النمط واحد في كل مكان: يُحسّن الذكاء الاصطناعي من أجل «أنه يعمل» ويعامل «من يُسمح له» كأنه مهمة شخص آخر. ومع توليد Lovable ما يقارب مليون مشروع أسبوعيًا، فإن عدد التطبيقات الحيّة القائمة على قاعدة بيانات مكشوفة ليس صغيرًا — والجزء الصعب لم يكن يومًا إطلاق العرض التجريبي. الجزء الصعب هو إبقاء البرمجية حيّة: مؤمَّنة، ومنشورة، ومُصانة.

طبِّق القائمة أعلاه وستُغلق بنفسك أخطر ثغرة في تطبيق Lovable النموذجي. وإن كنت تفضّل أن يتولّى مهندسو برمجيات وأمن كبار تدقيقه وإصلاحه وتأمينه وإطلاقه نيابةً عنك — بما في ذلك سياسات RLS والنشر وأساسيات الامتثال مثل PDPL/GDPR — فهذا الإنجاز الجاهز «done-for-you» هو تحديدًا ما تقدّمه Comestare.