تدقيق قاعدة بيانات Lovable: مشاكل الأمان، فجوات RLS، ومفاتيح API المكشوفة

جاء عميل إلينا الشهر الماضي بتطبيق تم إنشاؤه بواسطة Lovable وكان بالفعل مباشراً في الإنتاج مع عملاء يدفعون. أرادوا منا إضافة بعض الميزات و"تنظيف الأمور قليلاً". ما وجدناه خلال تدقيقنا الأولي لقاعدة الكود كان... مضيئاً. مفاتيح API مكشوفة في كود جانب العميل. سياسات الأمان على مستوى الصف مفقودة على الجداول التي تحتفظ ببيانات المستخدم. استدعاءات Supabase المباشرة بدون التحقق من صحة جانب الخادم. وهذا لم يكن حالة واحدة -- لقد قمنا الآن بتدقيق ستة مشاريع Lovable مختلفة، والأنماط متسقة بشكل ملحوظ.

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

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

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

• ما الذي ينشئه Lovable فعلاً
• مشكلة مفتاح API
• أمان مستوى الصف: القاتل الصامت
• فجوات المصادقة والتفويض
• تعريض منطق الأعمال من جانب العميل
• وظائف Supabase Edge: ما الذي يفتقد
• أنماط الثغرات الشائعة التي وجدناها
• كيفية تدقيق مشروع Lovable الخاص بك
• متى تعيد البناء مقابل متى تصلح
• الأسئلة الشائعة

ما الذي ينشئه Lovable فعلاً

ينشئ Lovable تطبيقات React (عادة باستخدام Vite) مع Tailwind CSS ومكونات shadcn/ui، متصلة بخادم Supabase الخلفي. المكدس نفسه سليم -- نحن نبني باستخدام هذه الأدوات نفسها بانتظام في عملنا تطوير Next.js. المشكلة ليست في خيارات التكنولوجيا. إنها كيفية توصيلها معاً.

إليك هيكل مشروع Lovable النموذجي:

src/
├── components/
│   ├── ui/           # مكونات shadcn
│   ├── Dashboard.tsx
│   ├── Settings.tsx
│   └── ...
├── integrations/
│   └── supabase/
│       ├── client.ts  # ← هنا تبدأ المشاكل
│       └── types.ts
├── pages/
├── hooks/
└── lib/

الكود المنشأ نظيف وسهل القراءة. سأعطي Lovable الفضل في ذلك. لكن القراءة السهلة لا تساوي الأمان. العمارة تتخذ قرارات موافقة للعرض التوضيحي ولكنها خطيرة للإنتاج.

دعني أكون محدداً.

مشكلة مفتاح API

كل مشروع Lovable قمنا بتدقيقه يحتوي على بيانات اعتماد Supabase في كود جانب العميل. الآن، قبل أن يظهر المدافعون عن Supabase: نعم، مفتاح anon مصمم ليكون عاماً. توثيق Supabase يوضح هذا صراحة. مفتاح anon مخصص للاستخدام في كود جانب العميل، والأمان يفترض أن يُفرض من خلال سياسات أمان مستوى الصف.

لكن هنا يصبح الأمر قبيحاً.

في ثلاثة من المشاريع الستة التي قمنا بتدقيقها، وجدنا مفتاح Supabase service_role إما:

1. مشفر بشكل مباشر في ملف أداة
2. مخزن في ملف .env تم الالتزام به في مستودع GitHub
3. المرجعية في وظيفة Supabase Edge كانت قابلة للوصول بدون مصادقة

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

// نمط فعلي وجدناه في مشروع Lovable (مفاتيح محجوبة)
import { createClient } from '@supabase/supabase-js'

// كان هذا في ملف يسمى lib/admin.ts
// مستورد ومستخدم في مكون جانب العميل
const supabaseAdmin = createClient(
  'https://xxxxx.supabase.co',
  'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...' // مفتاح service_role!
)

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

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

أمان مستوى الصف: القاتل الصامت

أمان مستوى الصف (RLS) هو آلية الأمان الأساسية في Supabase لحماية البيانات على مستوى قاعدة البيانات. عند تكوينها بشكل صحيح، فإنها تضمن أن المستخدمين يمكنهم فقط الوصول إلى بيانتهم الخاصة بغض النظر عن ما يتم إجراؤه من استدعاءات API من العميل.

عندما قمنا بتدقيق مشاريع Lovable الستة، إليك ما وجدناه:

المشروع	إجمالي الجداول	الجداول مع تفعيل RLS	الجداول مع سياسات RLS الصحيحة	البيانات الحساسة المكشوفة
لوحة معلومات SaaS	14	6	3	بيانات المستخدم الشخصية، بيانات الفواتير
تطبيق التجارة الإلكترونية	22	10	4	سجل الطلبات، العناوين
متتبع الصحة	11	4	2	السجلات الصحية، الأدوية
مدير المشروع	18	8	5	بيانات العميل، المستندات
منصة الحجز	16	7	3	معلومات الاتصال، الجداول الزمنية
أداة CRM	20	9	4	بيانات العملاء، الملاحظات

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

أكثر فشل RLS شيوعاً الذي نراه:

السياسات المفقودة تماماً

غالباً ما ينشئ Lovable جداول بدون تفعيل RLS على الإطلاق. في Supabase، يتم تعطيل RLS بشكل افتراضي على الجداول الجديدة، مما يعني أن أي شخص لديه مفتاح anon يمكنه قراءة كل البيانات.

-- ما نجده غالباً: RLS غير مفعل
CREATE TABLE public.user_profiles (
  id UUID REFERENCES auth.users,
  full_name TEXT,
  email TEXT,
  phone TEXT,
  created_at TIMESTAMPTZ DEFAULT NOW()
);
-- لا توجد ALTER TABLE ... ENABLE ROW LEVEL SECURITY;
-- لا توجد سياسات محددة

سياسات متساهلة جداً

عندما ينشئ Lovable RLS، فإن السياسات غالباً ما تكون واسعة جداً:

-- سياسة شائعة تم إنشاؤها بواسطة Lovable
CREATE POLICY "Users can view all profiles"
  ON public.user_profiles
  FOR SELECT
  USING (true);  -- هذا يسمح لأي مستخدم مصرح بقراءة جميع الملفات الشخصية

الإصلاح يجب أن يكون:

-- كما يجب أن يبدو
CREATE POLICY "Users can view own profile"
  ON public.user_profiles
  FOR SELECT
  USING (auth.uid() = id);

سياسات حذف وتحديث مفقودة

حتى عندما تكون سياسات SELECT صحيحة، سياسات INSERT/UPDATE/DELETE غالباً ما تكون مفقودة أو خاطئة. وجدنا حالات حيث يمكن لأي مستخدم مصرح تحديث ملف شخصي لمستخدم آخر.

فجوات المصادقة والتفويض

يتعامل Lovable مع المصادقة الأساسية بشكل معقول -- فإنه يعد Supabase Auth مع تسجيل الدخول عبر البريد الإلكتروني/كلمة المرور أو عمليات تسجيل الدخول الاجتماعية، وتدفقات تسجيل الدخول/الاشتراك تعمل بشكل عام. لكن المصادقة (من أنت؟) والتفويض (ماذا يمكنك أن تفعل؟) أشياء مختلفة.

طبقة التفويض شبه مكتملة أو معدومة دائماً تقريباً.

فكر في تطبيق SaaS متعدد المستأجر. ينتمي المستخدمون إلى منظمات. يجب أن يروا فقط البيانات من منظمتهم. قد يكون لديهم أدوار مختلفة (إدارة، عضو، متفرج). لا ينشئ Lovable أياً من هذا.

ما نجده عادة:

// جلب البيانات التي تم إنشاؤها بواسطة Lovable
const { data: projects } = await supabase
  .from('projects')
  .select('*')
  // لا يوجد فلتر لـ organization_id
  // لا يوجد فحص لدور المستخدم أو الأذونات

الإصلاح يتطلب كلا من التغييرات على مستوى قاعدة البيانات (RLS) وعلى مستوى التطبيق. تحتاج إلى جدول memberships يربط المستخدمين بالمنظمات مع الأدوار، وسياسات RLS التي تتحقق من العضوية، وكود التطبيق الذي يرشح بشكل مناسب.

هذا هو نوع عمل العمارة الذي يصعب تركيبه بعد الواقع. يلمس كل استعلام، كل مكون، كل صفحة. إذا كنت تبني SaaS متعدد المستأجرين مع Lovable، فهذا هو الشيء الذي سيعضك الأكثر صعوبة.

تعريض منطق الأعمال من جانب العميل

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

• حسابات التسعير مرئية وقابلة للتلاعب في أدوات DevTools للمتصفح
• أعلام الميزات للاشتراكات المختلفة يتم فحصها من جانب العميل
• رموز الخصم ومنطق التحقق من الصحة موجودة في حزمة JavaScript
• تحديد معدل API غير موجود (لا يوجد خادم لفرضه)

وجدنا SaaS واحد تم إنشاؤه بواسطة Lovable حيث فحص مستوى التسعير كان بالكامل من جانب العميل:

// وجد في مكون مشروع Lovable
const canAccessFeature = (feature: string) => {
  const plan = user?.subscription?.plan
  if (plan === 'pro') return true
  if (plan === 'basic' && BASIC_FEATURES.includes(feature)) return true
  return false
}

يمكن لمستخدم ببساطة تعديل هذه الدالة في وحدة تحكم المتصفح -- أو استدعاء Supabase API مباشرة بدون هذا الفحص -- والوصول إلى ميزات الخطة الاحترافية على خطة أساسية. لم تملك قاعدة البيانات سياسات تفرض الوصول بناءً على الخطة.

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

هذا بالضبط السبب في أننا غالباً ما نوصي بأطر عمل مثل Next.js أو Astro لتطبيقات SaaS الإنتاجية -- فإنها توفر لك العرض من جانب الخادم ومسارات API خارج الصندوق.

وظائف Supabase Edge: ما الذي يفتقد

بعض مشاريع Lovable تستخدم فعلاً وظائف Supabase Edge لعمليات معينة -- عادة ما يكون التعامل مع webhook Stripe أو إرسال رسائل البريد الإلكتروني. لكن التنفيذ غالباً ما يكون له مشاكل:

1. لا يوجد التحقق من صحة الإدخال: وظائف Edge تقبل وتعالج أي JSON يتم إرساله إليها بدون التحقق من الشكل أو الأنواع أو القيود.

2. تم تكوين CORS للسماح بكل الأصول:

// نمط شائع في وظائف Supabase Edge
const corsHeaders = {
  'Access-Control-Allow-Origin': '*',  // يسمح لأي موقع ويب باستدعاء هذا
  'Access-Control-Allow-Headers': 'authorization, x-client-info, apikey, content-type',
}

3. لا يوجد فحص مصادقة: الدالة لا تتحقق من توكن JWT، لذلك يمكن للمستخدمين غير المصرح لهم استدعاء الدالة.

4. توقيعات webhook Stripe لم يتم التحقق منها: في مشروعين، معالج webhook Stripe لم يتحقق من توقيع webhook، مما يعني أن أي شخص يمكنه إرسال أحداث دفع مزيفة إلى نقطة النهاية.

// ما وجدناه -- لا يوجد التحقق من التوقيع
Deno.serve(async (req) => {
  const body = await req.json()
  // يعالج الحدث مباشرة بدون التحقق من أنه جاء من Stripe
  if (body.type === 'checkout.session.completed') {
    // تحديث اشتراك المستخدم
    await supabaseAdmin.from('subscriptions').update({
      status: 'active',
      plan: 'pro'
    }).eq('user_id', body.data.object.metadata.user_id)
  }
})

هذا يعني أن المهاجم يمكنه إرسال طلب POST إلى عنوان URL لـ webhook مع حدث checkout.session.completed مزيف وترقية أي مستخدم إلى خطة احترافية مجاناً.

أنماط الثغرات الشائعة التي وجدناها

إليك ملخص للمشاكل الأكثر شيوعاً مرتبة حسب الخطورة والتكرار:

الثغرة	الخطورة	التكرار (من أصل 6)	سهولة الاستغلال
RLS مفقود على الجداول الحساسة	حرجة	6/6	سهل -- فقط استعلم الجدول
سياسات RLS متساهلة جداً	عالية	6/6	سهل باستخدام مفتاح anon
تعريض مفتاح service role	حرجة	3/6	تافه إذا تم اكتشافه
لا يوجد التحقق من توقيع webhook Stripe	عالية	4/6	متوسط -- تحتاج عنوان نقطة النهاية
التفويض من جانب العميل فقط	عالية	6/6	سهل باستخدام DevTools
لا يوجد التحقق من صحة الإدخال على وظائف Edge	متوسطة	5/6	متوسط
بطاقة CORS على وظائف Edge	متوسطة	5/6	سهل
البيانات الحساسة في localStorage	متوسطة	4/6	الوصول المادي أو XSS
لا يوجد تحديد معدل	متوسطة	6/6	تافه
المراجع المباشرة غير الآمنة للكائنات	عالية	5/6	سهل -- غير معرف في عنوان URL

كيفية تدقيق مشروع Lovable الخاص بك

إذا كنت قد بنيت شيئاً باستخدام Lovable يتعامل مع بيانات المستخدم الحقيقية، إليك كيفية التحقق من هذه المشاكل بنفسك.

الخطوة 1: تحقق من حالة Supabase RLS

انتقل إلى لوحة معلومات Supabase الخاصة بك → محرر الجدول. انقر على كل جدول وتحقق مما إذا تم تفعيل RLS. ثم انتقل إلى المصادقة → السياسات واستعرض كل سياسة.

أو قم بتشغيل هذا الاستعلام في محرر SQL:

SELECT
  schemaname,
  tablename,
  rowsecurity
FROM pg_tables
WHERE schemaname = 'public'
ORDER BY tablename;

إذا كان rowsecurity هو false لأي جدول يحتوي على بيانات المستخدم، فهذه مشكلة حرجة.

الخطوة 2: ابحث عن المفاتيح المكشوفة

في قاعدة الكود الخاصة بك، ابحث عن:

grep -r "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9" src/
grep -r "service_role" src/
grep -r "SUPABASE_SERVICE" src/

يطابق النمط الأول بداية مفاتيح Supabase JWT. إذا وجدت مفتاح service_role في أي مكان في مجلد src/ الخاص بك، فهذه ثغرة حرجة فورية.

الخطوة 3: اختبر سياسات RLS

أنشئ حساب مستخدم اختبار ثانٍ. سجل الدخول كمستخدم ثانٍ وحاول الوصول إلى بيانات المستخدم الأول. تحقق من علامة تبويب الشبكة في المتصفح -- هل تستقبل بيانات لا يجب أن تتلقاها؟

يمكنك أيضاً الاختبار مباشرة باستخدام curl:

curl 'https://YOUR_PROJECT.supabase.co/rest/v1/user_profiles?select=*' \
  -H "apikey: YOUR_ANON_KEY" \
  -H "Authorization: Bearer YOUR_ANON_KEY"

إذا أرجع هذا جميع ملفات تعريف المستخدم بدون مصادقة، فإن RLS مكسور.

الخطوة 4: تحقق من وظائف Edge

استعرض كل وظيفة Edge من أجل:

• التحقق من JWT
• التحقق من صحة الإدخال
• تكوين CORS
• التحقق من توقيع webhook (لمعالجات Stripe/الدفع)

الخطوة 5: فحص حزمة جانب العميل

قم بتشغيل npm run build وفحص الإخراج. ابحث في JavaScript المنشأ عن مفاتيح API ومنطق الأعمال وبيانات التسعير. أي شيء في الحزمة مرئي للمستخدمين.

متى تعيد البناء مقابل متى تصلح

هذا هو السؤال الذي يواجهه كل مؤسس Lovable مرة واحدة عندما يدركون أن هذه المشاكل موجودة. الإجابة تعتمد على عوامل عديدة:

أصلح إذا:

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

أعد البناء إذا:

• تحتاج إلى عمارة موكل متعدد مع أدوار وأذونات
• منطق عملك معقد وكله من جانب العميل
• تحتاج إلى العرض من جانب الخادم لـ SEO أو الأداء
• يحتوي نموذج Supabase على مشاكل هيكلية كبيرة
• أنت في مقياس حيث تحتاج إلى البنية الأساسية المناسبة

لإصلاحات، أنت عادة تنظر إلى إضافة سياسات RLS عبر كل الجداول، وهجرة منطق الأعمال الحساس إلى وظائف Edge أو طبقة جانب الخادم، وتنفيذ التحقق من صحة الإدخال المناسب، وإضافة تحديد معدل. هذا مشروع 2-4 أسابيع لمطور ذو خبرة حسب التعقيد.

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

إذا كنت غير متأكد من المسار الأنسب، فنحن سعداء بعمل تقييم سريع. اتصل بنا من خلال صفحة الاتصال.

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

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

هل يكشف Lovable مفاتيح Supabase API الخاصة بي؟ مفتاح Supabase anon مقصود أن يكون عاماً -- وهذا حسب التصميم، ونموذج الأمان في Supabase يأخذ هذا في الاعتبار من خلال RLS. المشكلة هي عندما يضع Lovable (أو أنت، من خلال الموجهات) مفتاح service_role في كود جانب العميل. كون مفتاح anon عاماً آمن فقط إذا كانت سياسات RLS الخاصة بك غير قابلة للكسر، والتي في مشاريع Lovable التي تم إنشاؤها، عادة ليست كذلك.

ما هو أمان مستوى الصف ولماذا يهم؟ أمان مستوى الصف (RLS) هو ميزة PostgreSQL التي تستخدمها Supabase للتحكم في الصفوف التي يمكن لمستخدم قراءتها أو إدراجها أو تحديثها أو حذفها. بدون RLS، يمكن لأي شخص لديه مفتاح anon العام الخاص بك الاستعلام عن قاعدة البيانات بأكملها -- بيانات كل مستخدم، كل سجل خاص. إنها آلية الأمان الأكثر أهمية في تطبيق Supabase، وهي أكثر شيء يتم تكوينه بشكل خاطئ في مشاريع Lovable.

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

كيف أتحقق من أن قاعدة بيانات تطبيق Lovable آمنة؟ الاختبار الأسرع: افتح أدوات المطور الخاصة بك، اذهب إلى علامة تبويب الشبكة، وانظر إلى استدعاءات Supabase API التي يجريها تطبيقك. انسخ قيمة رأس apikey. ثم استخدم curl أو Postman للاستعلام مباشرة عن جداولك باستخدام هذا المفتاح فقط بدون توكن auth. إذا حصلت على بيانات مستخدمين آخرين -- أو أي بيانات على الإطلاق على الجداول التي يجب أن تكون خاصة -- فإن RLS الخاص بك مكسور.

ما هي أكبر مخاطر الأمان مع الكود المنشأ بواسطة الذكاء الاصطناعي بشكل عام؟ منشئات الكود بالذكاء الاصطناعي تركز على جعل الأشياء تعمل، وليس على جعل الأشياء آمنة. ليس لديهم نموذج ذهني لمشهد التهديد الخاص بك. أكبر المخاطر هي: الأسرار المكشوفة، والتحقق من صحة الإدخال المفقود، وعناصر التحكم في الوصول المتساهلة جداً، وعدم وجود حدود أمان جانب الخادم. هذه ليست فريدة بالنسبة لـ Lovable -- المشاكل المماثلة موجودة في الكود من Cursor و v0 و Bolt وأدوات ذكاء اصطناعي أخرى. الفرق هو أن Lovable تنشئ تطبيقات كاملة يقوم الناس بنشرها مباشرة إلى الإنتاج.

هل يجب أن أتحول بعيداً عن Supabase بعد استخدام Lovable؟ Supabase نفسه جيد. إنها منصة صلبة بها قدرات أمان مناسبة. المشكلة هي كيف يقوم Lovable بتكوينها. لا تحتاج إلى التخلي عن Supabase -- تحتاج إلى تكوين سياسات RLS بشكل صحيح، ونقل العمليات الحساسة إلى وظائف Edge، وإضافة طبقة التفويض التي تجاهلها Lovable. البنية الأساسية جيدة؛ يحتاج التكوين فقط إلى عمل.

كم تكلفة إصلاح مشاكل الأمان في تطبيق Lovable المنشأ؟ للإصلاح المباشر -- إضافة سياسات RLS، تأمين وظائف Edge، إزالة المفاتيح المكشوفة، إضافة التحقق من صحة الإدخال الأساسي -- أنت تنظر إلى تقريباً 3000-8000 دولار حسب عدد الجداول وتعقيد نموذج التفويض الخاص بك. إعادة بناء كاملة مع عمارة مناسبة تجري من 15000-50000 دولار أو أكثر حسب النطاق. مسار الإصلاح أرخص دائماً تقريباً إذا كان نموذج البيانات الأساسي الخاص بك سليماً.