أفضل ممارسات أمان Supabase وRow Level Security
Row Level Security (RLS) في Supabase تعني أن قواعد الحماية تعمل داخل قاعدة البيانات نفسها، مهما كانت الطريقة التي يصل بها أي طلب إليها.
مفتاحان أساسيان: anon key (يخضع لـ RLS) وservice role key (يتجاوزه)
خطوة لا تؤجَّل أبدًا: تفعيل RLS فورًا عند إنشاء جدول جديد
حماية فعلية لجدول بدون سياسة RLS واضحة
Row Level Security (RLS) تتيح كتابة سياسات (Policies) تحدد من يمكنه قراءة أو تعديل كل صف في الجدول، وتُطبَّق هذه السياسات داخل قاعدة البيانات نفسها، بصرف النظر عن الطريقة التي يصل بها الطلب إليها.
الفرق بين anon key وservice role key
مفتاح anon key مخصص لكود العميل ويخضع بالكامل لسياسات RLS، بينما service role key يتجاوز RLS بالكامل ويملك صلاحيات كاملة — لذلك يجب أن يبقى فقط في كود السيرفر، وأبدًا في كود يصل إليه المتصفح.
خطأ شائع يجب تجنبه
إنشاء جدول جديد دون تفعيل RLS عليه فورًا، ظنًا أن "الإضافة لاحقًا" كافية — أي جدول بدون RLS مفعّل وسياسة واضحة، يكون مفتوحًا بالكامل لأي طلب يستخدم anon key إن لم تُحدد سياسات تقييدية.
أسئلة وأجوبة
01هل تفعيل RLS وحده كافٍ بدون سياسات؟
لا، تفعيل RLS بدون أي سياسة يمنع كل الوصول عبر anon key تمامًا؛ يجب كتابة سياسات (policies) واضحة تحدد الوصول المسموح فعليًا.
02متى أستخدم service role key بأمان؟
فقط في كود سيرفر موثوق تمامًا (مثل API routes أو سكريبتات إدارية)، وأبدًا في أي كود يمكن أن يصل إليه المتصفح أو يُكشف في bundle العميل.
هل تحتاج تطبيق هذه الأفكار في مشروعك؟
أقدم استشارات مجانية لمناقشة وضعك التقني الحالي وكيفية تحسينه.