تدقيق أمان تطبيقات Lovable 2026: المفاتيح المكشوفة وسياسات RLS المفقودة والثغرات التي تكتشفها التدقيقات

لقد قضيت الأشهر الثلاثة الماضية في تدقيق التطبيقات التي أحضرها العملاء إلينا بعد بناء نماذجهم الأولية على Lovable. النمط متسق جداً لدرجة أنه ممل تقريباً: مفاتيح خدمة Supabase المكشوفة في حزم العملاء، وسياسات RLS صفرية، وأسرار OpenAI و Stripe المرمزة بشكل صارم موجودة هناك في JavaScript لأي شخص لديه DevTools ليستخرجها. في كل مرة.

هذا ليس مقال هجوم على Lovable. المنصة مثيرة للإعجاب فعلاً للنماذج الأولية. لكن هناك فجوة بحجم الوادي بين "عرض توضيحي يعمل" و "تطبيق جاهز للإنتاج"، و Lovable لا تخبرك عن معظم ما يجلس في تلك الفجوة. قام باحث في المجتمع بتدقيق 50 تطبيقاً مدعوماً بالذكاء الاصطناعي ووجد نفس خمس أخطاء أمان في تقريباً جميعها. قام مطور آخر بفحص 200+ موقع مكود بالحدس ووجد متوسط درجة أمان 52 من أصل 100 - مع تركيز الجناة الأسوأ في تطبيقات Lovable + Supabase بالتحديد.

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

جدول المحتويات

تدقيق أمان تطبيقات Lovable 2026: المفاتيح المكشوفة وسياسات RLS المفقودة وما تكتشفه التدقيقات

البنية المعمارية التي تخلق المشكلة

لفهم سبب تأثر تطبيقات Lovable بشكل غير متناسب، تحتاج إلى فهم البنية المعمارية. Lovable يستخدم حصرياً Supabase كخادم خلفي. لا توجد خيارات Firebase، ولا خادم مخصص، ولا فرار. عندما تبني شيئاً في Lovable، فإنها تنتج واجهة أمامية React تتحدث مباشرة إلى Supabase REST API باستخدام مكتبة العميل.

تم تصميم Supabase بحيث يكون مفتاح anon آمناً للكشف عنه علناً - فهو يعرّف المشروع أساساً. يعتمد نموذج الأمان بالكامل على سياسات أمان مستوى الصف (RLS) على مستوى PostgreSQL. فكر فيها بهذه الطريقة:

المكون هل من المقصود أن يكون عاماً؟ ما الذي يحميك
عنوان URL الخاص بـ Supabase نعم لا شيء مطلوب - إنها مجرد عنوان URL
مفتاح anon نعم سياسات RLS على كل جدول
مفتاح service_role بالتأكيد لا يجب أن يبقى على جانب الخادم فقط
سلسلة الاتصال بقاعدة البيانات لا لا تكشفها أبداً للعملاء

المشكلة هي أن الذكاء الاصطناعي في Lovable ينتج رموزاً غالباً ما تعامل كل هذه بنفس الطريقة. يضع مفتاح anon في الواجهة الأمامية (حسناً)، لكن بعد ذلك ينشئ جداول بدون تفعيل RLS (كارثي). أحياناً يضع مفتاح service_role في رمز العميل أيضاً (انتهى اللعبة). كما قال أحد المطورين على Reddit: "الذكاء الاصطناعي يفعل ما تطلبه. فقط لا يفكر أبداً فيما لم تطلبه."

الثغرة 1: مفاتيح Supabase المكشوفة في رمز العميل

كل تطبيق Lovable يبدأ عميل Supabase بطريقة ما مثل هذا:

// src/integrations/supabase/client.ts
import { createClient } from '@supabase/supabase-js'

const supabaseUrl = 'https://xyzcompany.supabase.co'
const supabaseAnonKey = 'eyJhbGciOiJIUzI1NiIs...'

export const supabase = createClient(supabaseUrl, supabaseAnonKey)

وجود مفتاح anon هنا حسناً - هذا بالتصميم. تأتي المشكلة بشكلين:

تسرب مفتاح `service_role`

رأينا رموزاً تم إنشاؤها بواسطة Lovable حيث ينتهي مفتاح service_role في رمز جانب العميل، عادة لأن شخصاً ما طلب من الذكاء الاصطناعي شيئاً مثل "اجعل هذا يعمل حتى لو كان RLS يمنعه". حل الذكاء الاصطناعي؟ استخدم مفتاح المسؤول. مفتاح service_role يتجاوز جميع سياسات RLS تماماً. إذا كان في حزمة الواجهة الأمامية الخاصة بك، يمكن لأي شخص استخراجه والحصول على وصول كامل للقراءة/الكتابة لقاعدة البيانات الكاملة الخاصة بك.

ملف `.env` المرتكب إلى Git

غالباً ما تحتوي مشاريع Lovable المنتشرة إلى GitHub على ملفات .env مرتكبة إلى المستودع. حتى لو كان المستودع خاصاً الآن، إذا كان عاماً من قبل - حتى لمدة دقيقة واحدة - فقد تم الإساءة إلى تلك المفاتيح. تكشط البوتات GitHub باستمرار بحثاً عن هذا النمط بالضبط.

كيفية الفحص:

# ابحث في رمز المشروع عن مفاتيح service_role
grep -r "service_role" --include="*.ts" --include="*.tsx" --include="*.js" --include="*.env" .

# تحقق من سجل git للأسرار المرتكبة بطريق الخطأ
git log --all -p -- '*.env'

كيفية الإصلاح: أزل مفتاح service_role من جميع رموز العميل على الفور. قم بتدوير المفتاح في لوحة معلومات Supabase (الإعدادات → واجهة برمجية). استخدم المفتاح فقط في الرمز على جانب الخادم - Supabase Edge Functions أو مسار API في Next.js أو خادم منفصل.

الثغرة 2: سياسات RLS المفقودة أو المعطلة

هذه هي الكبيرة. كشفت CVE-2025-48757 عن 303 نقاط نهاية ضعيفة عبر 170+ تطبيق مدعوم بـ Lovable. وفقاً لـ Escape.tech، تتضمن 83% من قواعد بيانات Supabase المكشوفة سوء تكوين RLS.

إليك ما يحدث بشكل افتراضي عندما ينشئ Lovable جدولاً:

-- ما ينتجه Lovable في كثير من الأحيان
CREATE TABLE user_profiles (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id UUID REFERENCES auth.users(id),
  full_name TEXT,
  email TEXT,
  created_at TIMESTAMPTZ DEFAULT now()
);

-- لاحظ ما هو مفقود؟ RLS لم يتم تفعيله.
-- هذا الجدول قابل للقراءة والكتابة بالكامل من قبل أي شخص لديه مفتاح anon.

بدون RLS، قاعدة بيانات Supabase الخاصة بك هي أساساً واجهة برمجية عامة. أي شخص يعرف عنوان URL المشروع الخاص بك ومفتاح anon - كلاهما موجود في رمز الواجهة الأمامية - يمكنه فعل هذا:

// وحدة تحكم متصفح المهاجم
const { data } = await supabase.from('user_profiles').select('*')
// إرجاع بيانات كل المستخدمين

await supabase.from('user_profiles').delete().neq('id', '')
// حذف كل شيء

ثلاث نكهات من فشل RLS

وضع الفشل ما يحدث الخطورة
RLS غير مفعل على الإطلاق وصول عام كامل للقراءة/الكتابة حرجة
RLS مفعل لكن لا توجد سياسات محددة لا أحد يمكنه الوصول إلى أي شيء (التطبيق ينقطع) مرتفعة (تفرض المطورين تعطيل RLS)
السياسات المفرطة في الإذن (مثل USING (true)) تبدو آمنة، في الواقع ليست كذلك مرتفعة

الثالثة خاصة خادعة جداً. رأينا Lovable تنتج سياسات مثل هذه عندما يُطلب إصلاح "الأذونات":

CREATE POLICY "Allow all access" ON user_profiles
  FOR ALL
  USING (true)
  WITH CHECK (true);

هذا هو مسرح RLS. إنه مفعل، لديه سياسة، ولا يفعل شيئاً تماماً.

ما تبدو عليه السياسة المناسبة:

-- تفعيل RLS
ALTER TABLE user_profiles ENABLE ROW LEVEL SECURITY;

-- يمكن للمستخدمين فقط قراءة ملفهم الشخصي
CREATE POLICY "Users read own profile" ON user_profiles
  FOR SELECT
  USING (auth.uid() = user_id);

-- يمكن للمستخدمين فقط تحديث ملفهم الشخصي
CREATE POLICY "Users update own profile" ON user_profiles
  FOR UPDATE
  USING (auth.uid() = user_id)
  WITH CHECK (auth.uid() = user_id);

-- فقط المستخدمون المصرح لهم يمكنهم الإدراج، وفقط لأنفسهم
CREATE POLICY "Users insert own profile" ON user_profiles
  FOR INSERT
  WITH CHECK (auth.uid() = user_id);

تدقيق أمان تطبيقات Lovable 2026: المفاتيح المكشوفة وسياسات RLS المفقودة وما تكتشفه التدقيقات - البنية المعمارية

الثغرة 3: أسرار واجهة برمجية تابعة لطرف ثالث مرمزة بشكل صارم

هذا يجعلني أتألم في كل مرة. نعثر بانتظام على مفاتيح OpenAI API (sk-...)، مفاتيح Stripe السرية (sk_live_...)، مفاتيح SendGrid، وبيانات اعتماد أخرى مرمزة مباشرة في مكونات React.

// وجدت فعلاً في ملف تم إنشاؤه بواسطة Lovable
const openai = new OpenAI({
  apiKey: 'sk-proj-abc123...',  // هذا في حزمة المتصفح الخاصة بك
})

أي شخص يفتح DevTools، ويذهب إلى علامة التبويب Sources، والبحث عن sk- أو sk_live يحصل على مفاتيحك. المهاجمون يأتمتون هذا. هناك بوتات تزحف بشكل خاص على حزم JavaScript بحثاً عن هذه الأنماط.

الأثر المالي حقيقي. كان لدينا عميل جاء إلينا بعد أن أدى المفتاح المكشوف للـ OpenAI إلى رسوم بقيمة 4200 دولار على مدار عطلة نهاية الأسبوع. مفاتيح Stripe السرية أسوأ - فهي تمنح وصولاً كاملاً لمعالجة المبالغ المستردة وعرض بيانات العملاء وتعديل الاشتراكات.

الإصلاح: انقل جميع استدعاءات واجهة برمجية لطرف ثالث إلى وظائف على جانب الخادم. تعمل وظائف Supabase Edge بشكل جيد لهذا:

// supabase/functions/openai-proxy/index.ts
import { serve } from 'https://deno.land/std@0.168.0/http/server.ts'

serve(async (req) => {
  const { prompt } = await req.json()
  
  const response = await fetch('https://api.openai.com/v1/chat/completions', {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${Deno.env.get('OPENAI_API_KEY')}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      model: 'gpt-4o',
      messages: [{ role: 'user', content: prompt }],
    }),
  })
  
  return new Response(JSON.stringify(await response.json()))
})

الثغرة 4: رؤوس أمان مفقودة

وجد المسح الذي شمل 200+ موقع أن معظم تطبيقات Lovable المنتشرة تأتي بدون رؤوس أمان. لا Content-Security-Policy. لا Strict-Transport-Security. لا X-Frame-Options. لا X-Content-Type-Options.

قد يبدو هذا طفيفاً مقارنة بقاعدة بيانات مكشوفة، لكن الرؤوس المفقودة تمكّن:

  • Clickjacking - يمكن تضمين تطبيقك في iframe على موقع ضار
  • تضخيم XSS - بدون CSP، لا توجد قيود على البرامج النصية المحقونة
  • هجمات الكشف عن نوع MIME - قد تفسر المتصفحات الملفات كرمز قابل للتنفيذ
  • هجمات الانحدار - بدون HSTS، يمكن اعتراض حركة المرور
الرأس الغرض افتراضي Lovable
Content-Security-Policy يمنع XSS، يتحكم في تحميل الموارد مفقود
Strict-Transport-Security يفرض HTTPS مفقود
X-Frame-Options يمنع clickjacking مفقود
X-Content-Type-Options يمنع كشف MIME مفقود
Referrer-Policy يتحكم في معلومات الـ Referrer مفقود
Permissions-Policy يتحكم في ميزات المتصفح مفقود

الثغرة 5: عدم وجود التحقق من الإدخال أو التطهير

عادة ما تقوم النماذج التي تم إنشاؤها بواسطة Lovable بإرسال إدخال المستخدم مباشرة إلى Supabase بدون أي التحقق. لا فحوصات الطول، لا التحقق من النوع، لا تطهير HTML أو محتوى مشابه لـ SQL.

بينما طبقة PostgREST في Supabase تمنع SQL injection التقليدي، نقص التحقق من الإدخال لا يزال يمكّن:

  • Stored XSS من خلال HTML غير المطهر في حقول النص
  • Denial of Service من خلال حمولات كبيرة جداً
  • إساءة الاستخدام في منطق الأعمال (مثل الكميات السالبة، الأسعار بقيمة 0.00 دولار)
  • تلف البيانات من الأنواع غير المتوقعة

ما يتحقق منه فحص أمان Lovable المدمج فعلاً

يحتوي Lovable على ميزة "فحص أمان" مدمجة يمكن الوصول إليها من لوحة التحكم. يستحق الفضل - إنها موجودة. لكن إليك ما تغطيه فعلاً مقابل ما لا تفعله:

الفحص الفحص المدمج التدقيق الإنتاجي
أخطاء بناء الجملة الأساسية ✅ ✅
CVEs للاعتماديات المعروفة جزئي ✅
أسرار مرمزة في المصدر ❌ ✅
RLS مفعل على جميع الجداول ❌ ✅
صحة سياسة RLS ❌ ✅
تعريض مفتاح service_role ❌ ✅
رؤوس الأمان ❌ ✅
تغطية التحقق من الإدخال ❌ ✅
مراجعة تكوين المصادقة ❌ ✅
سياسات مجلد التخزين ❌ ✅
تحديد معدل الطلبات ❌ ✅
رايات أمان ملفات تعريف الارتباط ❌ ✅

الفحص المدمج سطحي في أحسن الأحوال. لن يلتقط الثغرات التي يتم استغلالها فعلاً.

ما يكتشفه التدقيق الإنتاجي الذي لا تكتشفه المنصة

عندما نقوم بتدقيق أمان إنتاجي لعميل قام ببناء تطبيق على Lovable، إليك ما نكتشفه ونصلحه عادة. هذه هي القائمة الحقيقية، من الاتفاقيات الفعلية:

طبقة قاعدة البيانات

  • الجداول مع تعطيل RLS (المتوسط: 60-70% من الجداول)
  • سياسات RLS باستخدام true كالشرط
  • سياسات مفقودة لعمليات الحذف (المطورون ينسون الحذف)
  • لا توجد سياسات على جداول التقاطع/الربط
  • دلاء التخزين مضبوطة على العام بدون قيود الرفع
  • مؤشرات مفقودة على الأعمدة المستخدمة في شروط سياسة RLS (الأداء + الأمان)

طبقة المصادقة

  • أسرار JWT ضعيفة (افتراضيات Supabase حسنة، لكن أحياناً الناس يغيرونها)
  • متطلبات تأكيد البريد الإلكتروني المفقودة
  • لا تحديد معدل الطلبات على نقاط نهاية المصادقة
  • تدفقات إعادة تعيين كلمات المرور بدون انتهاء صلاحية الرموز المناسبة
  • تكوينات رابط إعادة التوجيه OAuth الخاطئة

طبقة رمز العميل

  • مفاتيح service_role في حزم الواجهة الأمامية
  • مفاتيح واجهة برمجية تابعة لطرف ثالث مرمزة في المكونات
  • ملفات .env مرتكبة لسجل git
  • تسجيل تصحيح الأخطاء الذي يعرّض بيانات المستخدم في وحدة التحكم
  • رسائل الأخطاء التي تسرب معلومات مخطط قاعدة البيانات

طبقة البنية التحتية

  • لا توجد رؤوس أمان على الإطلاق
  • ملفات تعريف الارتباط بدون أعلام Secure أو HttpOnly أو SameSite
  • معلومات إصدار الخادم المكشوفة
  • لا تكوين CORS (يقبل الطلبات من أي أصل)
  • الاعتماديات بـ CVEs معروفة لم يتم تحديثها منذ أشهر

تطبيق Lovable الذي ننقّقه عادة يحتاج 15-25 إصلاح قبل أن يكون جاهزاً للإنتاج. معظمها يأخذ أقل من ساعة واحدة، لكنك تحتاج إلى معرفة أنها موجودة أولاً.

حادثة Moltbook: دراسة حالة واقعية

في يناير 2026، اكتشف باحثو الأمان في Wiz أن Moltbook - شبكة اجتماعية مدعومة بالذكاء الاصطناعي - كانت قاعدة بيانات Supabase الكاملة مكشوفة من خلال عميل تم تكوينه بشكل خاطئ. مفتاح anon كان في JavaScript الواجهة الأمامية (طبيعي)، لكن RLS لم يتم تكوينه على الجداول الحرجة (كارثي).

والنتيجة؟ 1.5 مليون مفتاح API كانت قابلة للوصول. ليس فقط بيانات المستخدم - مفاتيح API الفعلية التي تنتمي للمستخدمين الذين وصلوا حساباتهم في OpenAI وAnthropic وحسابات أخرى. وصول كامل للقراءة والكتابة إلى كل جدول. يمكن للباحث أن يستعرض قاعدة البيانات بالكاملة فقط باستخدام عميل Supabase في وحدة تحكم المتصفح.

كانت جدول الزمني للكشف محكومة - قام محافظ Moltbook بإصلاح الجداول الحرجة خلال ساعات من التواصل. لكن نافذة الضرر كانت غير معروفة. كم طويلاً كانت قاعدة البيانات مكشوفة قبل أن يفحص أحد؟ لا أحد يعرف.

هذا هو نمط Lovable + Supabase يلعب نفسه على نطاق واسع. المنصة تنتج رموزاً فاعلة. إنها فقط لا تنتج رموزاً آمنة.

كيفية إصلاح تطبيق Lovable قبل الذهاب للإنتاج

إليك قائمة التحقق التي نستخدمها. يمكنك القيام بمعظم هذا بنفسك إذا كنت مرتاحاً مع SQL ولوحة معلومات Supabase:

الخطوة 1: تدقيق كل جدول بحثاً عن RLS

-- قم بتشغيل هذا في محرر SQL الخاص بـ Supabase للعثور على جداول بدون RLS
SELECT schemaname, tablename, rowsecurity 
FROM pg_tables 
WHERE schemaname = 'public';

أي جدول حيث rowsecurity هو false يحتاج إلى اهتمام فوري.

الخطوة 2: ابحث في رمز المشروع عن الأسرار

# ابحث عن أنماط الأسرار الشائعة
grep -rn 'sk-' --include='*.ts' --include='*.tsx' --include='*.js' .
grep -rn 'sk_live' --include='*.ts' --include='*.tsx' --include='*.js' .
grep -rn 'service_role' --include='*.ts' --include='*.tsx' --include='*.js' .
grep -rn 'SUPABASE_SERVICE' --include='*.ts' --include='*.tsx' --include='*.env' .

الخطوة 3: اكتب سياسات RLS المناسبة

لكل جدول، اكتب سياسات صريحة للاختيار والإدراج والتحديث والحذف. استخدم دائماً فحوصات auth.uid():

-- قالب لجدول مملوك للمستخدم
ALTER TABLE your_table ENABLE ROW LEVEL SECURITY;

CREATE POLICY "select_own" ON your_table FOR SELECT
  USING (auth.uid() = user_id);

CREATE POLICY "insert_own" ON your_table FOR INSERT
  WITH CHECK (auth.uid() = user_id);

CREATE POLICY "update_own" ON your_table FOR UPDATE
  USING (auth.uid() = user_id)
  WITH CHECK (auth.uid() = user_id);

CREATE POLICY "delete_own" ON your_table FOR DELETE
  USING (auth.uid() = user_id);

الخطوة 4: انقل استدعاءات واجهة برمجية لجانب الخادم

يجب أن يعمل أي استدعاء واجهة برمجية لطرف ثالث يتطلب مفتاحاً سرياً في وظيفة Supabase Edge أو خادم منفصل. هذا غير قابل للتفاوض.

الخطوة 5: أضف رؤوس أمان

إذا كنت تنشر إلى Netlify أو Vercel أو Cloudflare، أضف الرؤوس عبر تكوينهم. بالنسبة إلى Netlify، أنشئ ملف _headers. بالنسبة لتطبيق Next.js، أضفها في next.config.js.

الخطوة 6: ضع في الاعتبار ترحيل الإطار

بالنسبة لأي شيء يتجاوز MVP، غالباً ما نوصي بترحيل رمز React الذي تم إنشاؤه بواسطة Lovable إلى مشروع Next.js أو Astro مناسب. هذا يعطيك مسارات API على جانب الخادم، معالجة مناسبة لمتغيرات البيئة، middleware لفحوصات المصادقة، وخط أنابيب بناء حقيقي. إنها أكثر عملاً مسبقاً، لكن موقف الأمان يكون مختلفاً تماماً.

أدوات للمسح الآلي

ظهرت عدة أدوات بشكل خاص لتدقيق التطبيقات التي تم إنشاؤها بواسطة الذكاء الاصطناعي:

الأداة ما الذي تتحقق منه السعر
Ship Safe (npx ship-safe audit .) RLS وتعريض service_role ودلاء التخزين و CVEs للاعتماديات مجاني، مفتوح المصدر
Vibe App Scanner (vibeappscanner.com) مسح أمان كامل للتطبيقات التي تم إنشاؤها بواسطة الذكاء الاصطناعي مسح بدء مجاني
Snyk ثغرات الاعتماديات ومسح الرمز طبقة مجانية متاحة
لوحة معلومات Supabase → Auth → Policies محرر سياسة RLS البصري مضمن مع Supabase

Ship Safe هي التي سأبدأ بها. إنها تعمل محلياً، لا شيء يترك آلتك، وتم بناؤها خصيصاً لسوء تكوينات Supabase التي تنشئها أدوات الذكاء الاصطناعي:

npx ship-safe audit .

سوف تحتج من RLS المعطل ومفاتيح service_role في رمز العميل ودلاء التخزين المفتوحة وتكوين المصادقة الضعيف والأسرار المرمزة و CVEs للاعتماديات.

الأسئلة الشائعة

هل مفتاح anon الخاص بـ Supabase آمن للكشف عنه في رمز الواجهة الأمامية؟ نعم - لكن فقط إذا كان لديك سياسات RLS مناسبة على كل جدول. مفتاح anon مصمم ليكون عاماً. إنه يشبه معرّف المشروع. يأتي الأمان من سياسات RLS التي تتحكم في ما يمكن لهذا المفتاح الوصول إليه بالفعل. بدون RLS، يعطي مفتاح anon أي شخص وصول كامل إلى قاعدة البيانات.

هل يفعل Lovable تفعيل RLS افتراضياً عند إنشاء جداول؟ لا. اعتباراً من أوائل 2026، ينشئ Lovable جداول Supabase بدون تفعيل RLS افتراضياً. هذا هو أكبر فجوة أمان في المنصة. تحتاج إلى تفعيل RLS يدويً وكتابة سياسات لكل جدول بعد أن ينتجها Lovable. كانت CVE-2025-48757 نتيجة مباشرة لهذا السلوك الافتراضي.

كيف أتحقق مما إذا كان تطبيق Lovable الخاص بي يحتوي على أسرار مكشوفة؟ افتح تطبيقك المنتشر في متصفح، افتح DevTools (F12)، اذهب إلى علامة التبويب Sources، وابحث عبر جميع الملفات عن sk- و sk_live و service_role وأي بادئات مفتاح API للخدمات التي تستخدمها. قم أيضاً بتشغيل npx ship-safe audit . محلياً على رمز المشروع الخاص بك للكشف الآلي.

هل يمكن لفحص أمان Lovable المدمج أن يكتشف مشاكل RLS؟ لا يتحقق فحص الأمان المدمج من عدم تكوينات RLS أو السياسات المفقودة أو مفاتيح service_role المكشوفة. يغطي المشاكل على مستوى الرمز الأساسية لكنه يفتقد ثغرات قاعدة البيانات والبنية التحتية التي تمثل أعلى مخاطر. تحتاج إلى أدوات خارجية لتقييم أمان حقيقي.

ماذا حدث مع CVE-2025-48757؟ كانت CVE-2025-48757 إفصاح ثغرة عن 303 نقطة نهاية ضعيفة عبر 170+ تطبيق مدعوم بـ Lovable. السبب الجذري كان Lovable ينشئ جداول Supabase بدون تفعيل RLS، مما يترك قواعد بيانات كاملة متاحة لأي شخص لديه مفتاح anon العام المتاح. سلطت الضوء على الطبيعة المنهجية للمشكلة.

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

كم من الوقت يستغرق تأمين تطبيق Lovable للإنتاج؟ لتطبيق نموذجي يحتوي على 10-20 جدول، توقع 2-5 أيام من العمل المركز لتدقيق جميع سياسات RLS ونقل الأسرار إلى جانب الخادم وإضافة رؤوس أمان والتحقق من الإدخالات واختبار كل شيء. التطبيقات الأكثر تعقيداً بدلاء التخزين والاشتراكات في الوقت الفعلي وأدوار المستخدمين المتعددة قد تستغرق وقتاً أطول. إنها ليست مهمة لمدة ساعة واحدة، لكنها ليست مستحيلة.

هل منشئو تطبيقات ذكاء اصطناعي آخرون مثل Bolt أو Cursor أكثر أماناً من Lovable؟ وجد المسح الذي شمل 200+ موقع أن الثغرات الأمنية كانت مركزة في تطبيقات Lovable + Supabase بشكل خاص. لم تظهر تطبيقات Bolt وReplit وCursor/Cline نفس نمط سوء تكوين RLS. هذا لا يعني أنها آمنة تماماً - جميع الرموز التي تم إنشاؤها بواسطة الذكاء الاصطناعي تحتاج إلى مراجعة - لكن تكامل Lovable-Supabase المحدد ينشئ فئة فريدة من ثغرات تعريض قاعدة البيانات التي لا تملكها أدوات أخرى.