17 جدولاً مكشوفاً للعلن: كيف تسببت إعدادات Supabase الافتراضية في تسريب بيانات حساسة؟

مقدمة تحليلية

في عالم الحوسبة السحابية وقواعد البيانات المدارة، غالباً ما يثق المطورون في أن المنصات الكبرى مثل Supabase توفر بيئة آمنة افتراضياً. ومع ذلك، كشف تقرير تقني حديث عن فجوة أمنية حرجة تتعلق بكيفية تعامل المنصة مع جداول البيانات في المخطط العام (public schema) وعلاقتها بمفتاح الوصول المجهول (anon key). القصة بدأت عندما أعلنت Supabase عن تحديث جذري في مايو 2026 ينهي حقبة 'التعرض التلقائي' للجداول لواجهة برمجة تطبيقات البيانات (Data API)، مما دفع المطورين لإعادة فحص مشاريعهم ليكتشفوا واقعاً صادماً: بيانات حساسة كانت متاحة لأي شخص يمتلك مفتاح API المجهول الموجود في شيفرة جافا سكريبت الخاصة بمواقعهم.

هذا الكشف ليس مجرد خطأ عابر، بل هو انعكاس لنموذج 'السرعة قبل الأمن' الذي ساد لفترة طويلة في أدوات التطوير الحديثة. إن اعتماد المطورين على Row Level Security (RLS) كشبكة أمان وحيدة، مع نسيان تفعيلها في بعض الجداول، خلق ثغرات سمحت بالوصول إلى بيانات مثل قوائم العملاء المحتملين (B2B Leads) ومقاييس النمو الداخلية دون أي صلاحيات رسمية.

التحليل التقني

تعتمد بنية Supabase الأمنية بشكل أساسي على محرك PostgreSQL وميزة Row Level Security (RLS). عندما يتم إنشاء جدول جديد، كانت الإعدادات الافتراضية للمنصة (حتى التحديث الأخير) تمنح صلاحيات القراءة والكتابة (CRUD) للدور `anon` بشكل تلقائي عبر واجهة PostgREST. التحليل التقني يوضح أن الثغرة تكمن في 'النقاط العمياء' التالية:

• تعطيل RLS مع منح صلاحيات anon: الجداول التي يتم إنشاؤها عبر لوحة التحكم دون تفعيل خيار RLS يدوياً تصبح مفتوحة تماماً أمام أي طلب يستخدم مفتاح anon.
• وظائف SECURITY DEFINER: الدوال البرمجية التي تعمل بصلاحيات المشرف ولكن يمكن استدعاؤها من قبل المستخدم المجهول (RPC)، مما قد يؤدي لتسريب بيانات إحصائية أو تعديل سجلات حساسة.
• التخزين العام (Public Storage): حاويات التخزين التي تفتقر لسياسات وصول صارمة، مما يسمح بسحب ملفات المستخدمين مباشرة.
• امتيازات التقصير (Default Privileges): حتى مع قفل الجداول الحالية، تظل الجداول المستقبلية عرضة للخطر إذا لم يتم تعديل صلاحيات المخطط العام عبر أمر `ALTER DEFAULT PRIVILEGES`.

لمواجهة هذا، تم تطوير أداة تدقيق برمجية بلغة Node.js تعتمد على الاستعلام المباشر من جداول النظام في PostgreSQL مثل `pg_class` و `pg_policies`. الأداة تقوم بفحص التوليفة القاتلة: 'جدول بدون RLS + وجود منح صلاحيات للدور anon'. هذا النوع من التدقيق يتفوق على أدوات Supabase المدمجة حالياً لأنها لا تنبه المطور بوضوح إلى أن الجدول ليس فقط غير محمي بـ RLS، بل إنه متاح تقنياً عبر الـ API العام.

السياق وتأثير السوق

توقيت هذا الكشف يتقاطع مع المواعيد النهائية الصارمة التي وضعتها Supabase: 30 مايو 2026 للمشاريع الجديدة، و30 أكتوبر 2026 لفرض السلوك الجديد على جميع المشاريع القائمة. هذا يعكس ضغطاً هائلاً على سوق تطبيقات SaaS التي تعتمد على البنية التحتية 'الخلفية كخدمة' (BaaS). تاريخياً، واجهت منصات مثل Firebase انتقادات مشابهة بشأن 'قواعد الأمان' (Security Rules) الضعيفة التي أدت لتسريبات ضخمة.

السوق الآن يتجه نحو مفهوم 'Secure by Design' حيث يتم إغلاق كل شيء افتراضياً. التأثير المباشر سيكون زيادة في تكلفة الصيانة التقنية للمشاريع القديمة، حيث سيتعين على الفرق الهندسية مراجعة آلاف الجداول والسياسات لضمان عدم تعطل تطبيقاتهم عند حلول الموعد النهائي في أكتوبر 2026.

رؤية Glitch4Techs

في Glitch4Techs، نرى أن هذه الحادثة تبرز إشكالية عميقة في أدوات 'التطوير السريع'. إن توفير 'مفتاح مجهول' (anon key) يمتلك صلاحيات واسعة على قاعدة البيانات هو قرار معماري محفوف بالمخاطر منذ البداية. نصيحتنا التقنية تتجاوز مجرد تفعيل RLS؛ يجب على المطورين تبني استراتيجية 'الدفاع العميق' (Defense-in-Depth) من خلال:

• التعامل مع مفتاح anon على أنه 'مكشوف' دائماً، وبالتالي لا يجب أن يمتلك أي صلاحيات افتراضية على أي جدول جديد.
• استخدام أدوات تدقيق محلية (Local Auditing) لا تتطلب إرسال مفاتيح الوصول إلى خدمات طرف ثالث (SaaS)، لضمان عدم تسريب 'مفاتيح المملكة' أثناء فحص الأبواب.
• تفعيل سياسة 'الرفض الافتراضي' (Default Deny) عبر SQL لتعطيل الصلاحيات التلقائية في PostgreSQL.

ختاماً، إن اكتشاف 17 جدولاً مكشوفاً في مشروع 'مؤمن' هو جرس إنذار لكل من يدير قاعدة بيانات على Supabase. أكتوبر 2026 ليس بعيداً، والثغرات الموجودة اليوم قد تكون ثغرات صفرية (Zero-day) في يد المهاجمين غداً إذا لم يتم التحرك فوراً.