قائمة فحص أمان تطبيق Lovable: هل تطبيقك آمن؟
منصة Lovable والتطبيق الذي بنيته عليها يُؤمَّنان كلٌّ على حدة. يفحص Lovable الأخطاء الشائعة، لكن تطبيقك آمن بقدر قواعد الوصول ومفاتيحه وشيفرة الخادم الخاصة به فقط. تحقق من أن أمان مستوى الصف مفعّل على كل جدول مكشوف ويطابق من يحق له رؤية ماذا، وأن أي مفتاح سري لا يصل إلى المتصفح، وأن المدفوعات مؤكدة على الخادم، وأن هناك من يراقب التطبيق الحي.
- وراء CVE-2025-48757
- أمان مستوى الصف معطّل، أو واسع أكثر من اللازم
- آمن للإرسال
- مفتاح Supabase القابل للنشر (anon)
- لا تُرسله أبدًا
- مفتاح service role أو أي مفاتيح سرية أخرى
- أعد الفحص
- بعد كل تغيير يمس البيانات أو الوصول
هل Lovable آمن، وهل يجعل ذلك تطبيقي آمنًا؟
يقول Lovable إنه يدعم متطلبات SOC 2 وGDPR، وينشر وثائق الأمان في مركز الثقة الخاص به. وهذا يغطي منصة Lovable: بنيتها التحتية وضوابط الوصول فيها وموظفيها. لكنه لا يغطي القواعد داخل تطبيقك، لأنك أنت (بمساعدة Lovable) من كتبها.
يجري فحص الأمان في Lovable فحصًا سريعًا في كل مرة تنشر فيها: مراجعة لقاعدة البيانات، وتدقيقًا للمكتبات المعتمدة، وفحصًا لخادم MCP. وفحص أعمق، يُبدأ يدويًا (أو وفق جدول لعملاء Lovable Enterprise)، يراجع أيضًا التحكم في الوصول، ونقاط النهاية غير المصادَق عليها، والحقن، والأسرار المسرّبة، والمدفوعات، والمصادقة، والبيانات الشخصية المكشوفة. ووثائق Lovable نفسها واضحة في أن هذه الأدوات لا تستطيع ضمان أمان كامل. عامل الفحص كجهاز إنذار دخان، لا كتفتيش.
ما كانت CVE-2025-48757، وهل تؤثر في تطبيقي؟
تصف CVE-2025-48757، المنشورة في مايو 2025، سياسات أمان مستوى صف غير كافية في المواقع التي أنشأها Lovable حتى 15 أبريل 2025، سمحت لمهاجمين غير مصادَق عليهم بقراءة جداول قاعدة البيانات أو الكتابة فيها. وتدرجها قاعدة بيانات الثغرات الوطنية الأمريكية بدرجة CVSS 3.1 حرجة تبلغ 9.3، وتشير إلى أن Lovable يعترض عليها، على أساس أن كل عميل مسؤول عن حماية بيانات تطبيقه.
يقول الباحث الذي أبلغ عنها، مات بالمر، إنه فحص 1,645 مشروعًا ووجد 303 نقاط نهاية معرضة للخطر في 170 منها، وإن Lovable أطلق فحص الأمان مع Lovable 2.0 في أبريل 2025. وأيًا كان رأيك في الخلاف، فالدرس العملي واحد: إن أُنشئ تطبيقك قبل ذلك، أو غيّرت الجداول منذ ذلك الحين، فافحص سياساتك بنفسك. السياسة الموجودة ليست بالضرورة السياسة الصحيحة.
ماذا يجب أن تغطي قائمة فحص أمان Lovable؟
| الفحص | لماذا يهم | كيف تختبره |
|---|---|---|
| RLS مفعّل على كل جدول في مخطط مكشوف | دونه، يسمح Supabase لأي دور لديه صلاحية بقراءة الجدول كله والكتابة فيه | شغّل Security Advisor في Supabase؛ القاعدة 0013 (rls_disabled_in_public) تنبّه إليه |
| السياسات تطابق قواعدك | سياسة مثل USING (true) تجتاز الفحص ومع ذلك تسمح للجميع بالمرور | سجّل الدخول كالمستخدم A، واطلب صفوف المستخدم B عبر الواجهة البرمجية، وتوقع ألا يعود شيء |
| جداول فيها RLS بلا سياسة | ترفض كل شيء، فيظهر ذلك كميزة معطلة لا كتسرب | قاعدة المستشار 0008 (rls_enabled_no_policy)؛ ثم اكتب السياسة التي تحتاجها الميزة |
| لا مفاتيح سرية في المتصفح | مفتاح service role يتجاوز كل سياسات RLS | ابحث في JavaScript المبني عن sb_secret_ أو مفتاح service_role قديم؛ وبدّل أي مفتاح أُرسل يومًا |
| فحوص على الخادم لكل ما يكلف مالًا | يستطيع مستخدم شيفرة العميل تعديلها | استدعِ دالة الحافة مباشرة بسعر أو خطة معدّلة وتوقع الرفض |
| تحديد معدل الطلبات على التسجيل وتسجيل الدخول واستدعاءات الذكاء الاصطناعي | الطلبات غير المحدودة تتحول إلى إساءة استخدام أو فاتورة مفاجئة | على البيئة التجريبية، أرسل 100 طلب سريع عبر سكربت وتأكد من رفض معظمها |
| الحماية من كلمات المرور المسرّبة والمصادقة متعددة العوامل للمسؤولين | كلمات المرور المعاد استخدامها من اختراقات أخرى طريق دخول شائع | جرّب كلمة مرور معروف أنها مسرّبة عند التسجيل |
| سجل تدقيق ومراقبة الأخطاء | لا تستطيع التحقيق فيما لم تسجّله | أجرِ تغييرًا إداريًا في البيئة التجريبية وابحث عنه في السجل |
كيف أصلح أخطاء RLS في Supabase في تطبيق Lovable؟
تأتي أخطاء RLS في نوعين متعاكسين، ومن المفيد أن تعرف أيهما لديك.
- رفض الصلاحية (خطأ Postgres رقم 42501، أو نتيجة فارغة). RLS مفعّل ولا سياسة تسمح بالطلب. هذا يعني أن RLS يعمل. اكتب أضيق سياسة تجعل الميزة تعمل، مثل الصفوف التي يساوي فيها عمود المالك معرّف المستخدم المسجّل.
- كل شيء يعمل للجميع. الحالة الأخطر. سياسة مثل USING (true)، أو مفتاح RLS غير مفعّل، تسمح لأي مستخدم بالمرور. ينبّه مستشار Supabase إلى السياسات المتساهلة (القاعدة 0024، permissive_rls_policy) والسياسات الموجودة بينما RLS معطّل (القاعدة 0007، policy_exists_rls_disabled).
- سياسات تقرأ بيانات المستخدم الوصفية. يحذّر Supabase من بناء السياسات على بيانات وصفية يستطيع المستخدم تعديلها بنفسه (القاعدة 0015، rls_references_user_metadata). استخدم بدلًا منها جدولًا يتحكم فيه خادمك، مثل جدول عضوية الفريق.
حين تطلب من Lovable إصلاح سياسة، أعد اختبار المستخدمَين بعد ذلك. فالأمر الذي يُخفي خطأً قد يفعل ذلك بتوسيع الوصول، وهو بالضبط الفشل الذي تحاول منعه.
أي المفاتيح آمن كشفها في تطبيق Lovable؟
تقول وثائق Supabase إن المفتاح القابل للنشر (anon) آمن للكشف، لأنه لا يصل إلا إلى ما يسمح به أمان مستوى الصف. أما المفتاح السري، بما فيه مفتاح service role، فيتجاوز كل سياسات RLS ويجب ألا يوضع أبدًا في متصفح أو تطبيق منشور أو نظام إدارة الشيفرة المصدرية. ويشرح مدخل المصطلحات عن مفتاح anon ومفتاح service role الفرق بينهما. أما أسرار الأطراف الثالثة، مثل مفاتيح Stripe أو مزود البريد الإلكتروني، فمكانها أسرار دوال الحافة، لا شيفرة التطبيق. راجع إدارة الأسرار.
كم مرة يجب إعادة فحص تطبيق Lovable الحي؟
بعد كل تغيير يمس البيانات أو الوصول أو المدفوعات، ووفق جدول لكل ما عدا ذلك: تظهر ثغرات جديدة في المكتبات المعتمدة، ويجب تبديل المفاتيح، وتصل جداول جديدة بسياسات جديدة. لهذا يعمل الأمان بشكل أفضل كعادة منه كتدقيق. وفي خططنا، تُجرى فحوص الأمان ومراجعة الشيفرة واختبارات الانحدار على كل تغيير قبل أن يصل إلى بيئة الإنتاج، ويوافق عليه مهندس غير كاتبه.
الأسئلة الشائعة
هل Lovable آمن للاستخدام في تطبيق أعمال حقيقي؟
Lovable مكان معقول لبناء تطبيق وتصميمه، ويفحص الأخطاء الأمنية الشائعة. أما ما إذا كان التطبيق النهائي آمنًا فيعتمد على قواعد الوصول ومفاتيحه وشيفرة الخادم الخاصة به، وعليك التحقق منها قبل وصول المستخدمين والبيانات الحقيقية. وتقول وثائق Lovable إن فحوصه لا تستطيع ضمان أمان كامل.
هل مفتاح Supabase anon في تطبيقي على Lovable مشكلة أمنية؟
لا. توثّق Supabase المفتاح القابل للنشر (anon) بأنه آمن للكشف، لأنه لا يصل إلا إلى ما يسمح به أمان مستوى الصف. ويصبح مشكلة فقط حين يكون RLS معطلًا أو واسعًا أكثر من اللازم. أما مفتاح service role فمختلف: إنه يتجاوز RLS ويجب ألا يكون في المتصفح أبدًا.
هل لا تزال CVE-2025-48757 تؤثر في تطبيقات Lovable؟
تغطي CVE المواقع التي أنشأها Lovable حتى 15 أبريل 2025، وLovable يعترض عليها. وقد أضاف Lovable منذ ذلك الحين فحصًا أمنيًا. لكن أي تطبيق، قديمًا أو جديدًا، قد يُطلق بسياسة واسعة أكثر من اللازم، لذا اختبر جداولك بحسابي مستخدمَين بدل الاعتماد على التاريخ.
كم تكلف مراجعة أمنية لتطبيق Lovable؟
يبيع كثير من المطورين المستقلين والشركات مراجعات لمرة واحدة بسعر ثابت. وفي خطة Plutonapps، تُجرى فحوص الأمان ومراجعة الشيفرة على كل تغيير ضمن السعر الشهري، إلى جانب بناء التطبيق واختباره وإصداره وتشغيله. الخطط والأسعار في صفحة الأسعار لدينا.
هل يمكنني إجراء فحوص الأمان بنفسي؟
نعم. يجري Lovable فحصه السريع عند النشر، وSecurity Advisor من Supabase موجود في لوحة تحكم مشروعك، واختبار المستخدمَين في قائمة الفحص لا يحتاج إلا إلى حسابي اختبار. أما الأصعب وحدك فهو الاستمرار في ذلك مع كل تغيير، ما دام التطبيق يعمل.
من أعمالنا
المصطلحات في هذه الصفحة
مقارنات وأدلة ذات صلة
- تطبيق Lovable لا يعمل في بيئة الإنتاج؟ كيف تجعله جاهزًا للإنتاج — لماذا تتعطل التطبيقات التي تعمل في المعاينة مع المستخدمين الحقيقيين، والفحوص التي تجعلها جاهزة للإنتاج، ومن يبقيها تعمل.
- كيف تنتقل من Lovable Cloud إلى مشروع Supabase خاص بك — Lovable Cloud أم Supabase خاص بك، وما يتضمنه التصدير وما يتركه، وخطة انتقال تُبقي بيئة الإنتاج تعمل.
- كيف توظف مطور Lovable (وكم يكلف ذلك) — مقارنة بين المطورين المستقلين ووكالات شركاء Lovable واشتراكات الهندسة في التكلفة والنطاق ومن يشغّل التطبيق بعد ذلك.
- الخطط والأسعار
المصادر
تم التحقق من كل معلومة خارجية في هذه الصفحة مقابل المصدر المرتبط في 30 September 2026. تتغير الأسعار والخطط؛ اتبع الروابط للأرقام الحالية.