أمن قواعد البيانات: دليل شامل لسياسات RLS في Supabase

سياسات الأمان على مستوى الصف (Row Level Security) هي القلب النابض لأمن أي تطبيق Supabase. تعطيلها أو تكوينها بشكل خاطئ يُعرّض كل بيانات مستخدميك للخطر، وهذا خطأ نراه بشكل متكرّر في مراجعات الأمان.

القاعدة الذهبية: كل جدول في المخطط العام (public) يجب أن يُفعّل عليه RLS، حتى لو لم يكن يحتوي بيانات حسّاسة. ثم تُضاف سياسات صريحة لكل عملية (SELECT, INSERT, UPDATE, DELETE) بشكل منفصل.

من الأخطاء الشائعة: تخزين الأدوار (roles) في نفس جدول الملفات الشخصية. هذا يفتح ثغرة صلاحيات (privilege escalation) لأن المستخدم قد يُحدّث حقل دوره الخاص. الحل: جدول user_roles منفصل مع دالة has_role موقّعة SECURITY DEFINER.

مثال على سياسة صحيحة لجدول 'orders' يسمح للمستخدم برؤية طلباته فقط: CREATE POLICY "users read own orders" ON public.orders FOR SELECT TO authenticated USING (auth.uid() = user_id);

لا تنسَ GRANT. Supabase لم يعد يمنح صلاحيات افتراضية على المخطط العام لدور anon أو authenticated. بعد كل CREATE TABLE، أضف GRANT SELECT, INSERT, UPDATE, DELETE ON public.table_name TO authenticated;

للعمليات التي تحتاج تجاوز RLS (مثل تقارير المشرف)، استخدم عميل service_role حصراً في كود الخادم، ولا تكشفه أبداً للمتصفح. تسريب هذا المفتاح يعني الوصول الكامل لكل بياناتك.

اختبار السياسات ضروري قبل النشر. أنشئ مستخدمَي اختبار بأدوار مختلفة، وحاول القيام بعمليات يجب أن تُرفض. Supabase Studio يُوفّر واجهة سهلة لمحاكاة هذه السيناريوهات.

من الأدوات المفيدة: امتداد pg_audit لتسجيل كل عمليات القراءة والكتابة الحسّاسة، وهو ضروري في التطبيقات المالية أو الصحية للامتثال التنظيمي.

التدقيق الدوري لا يُغني عنه شيء. جدول مراجعة أمنية كل ٣ أشهر يُساعد على اكتشاف السياسات الفضفاضة أو الجداول المكشوفة قبل أن يكتشفها المهاجم.

الأمن ليس ميزة تُضاف لاحقاً، بل قرار معماري يبدأ من اليوم الأول. المؤسسات التي تعامل الأمن كأولوية، تُوفّر لاحقاً تكاليف باهظة من الحوادث والاختراقات.