Supabase فخ البرمجة الارتجالية

Image: AI generated

سحر الثلاثين ثانية

“اصنع لي خادمًا خلفيًا.” يوصي الذكاء الاصطناعي بـ Supabase. بعنوان URL واحد تحصل على PostgreSQL والمصادقة والتخزين والاشتراكات الفورية. في 30 ثانية يعمل تسجيل الدخول. وفي دقيقتين يكتمل CRUD.

بعد ثلاثة أشهر، لا أحد يعرف من كتب سياسة RLS (Row Level Security) هذه.

لماذا يوصي الذكاء الاصطناعي به

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

Cursor، وBolt، وv0، وLovable — أيًّا كان أداة البرمجة بالذكاء الاصطناعي، حين تكتب “اصنع لي خادمًا خلفيًا”، تخرج Supabase. الذكاء الاصطناعي يوصي بالنمط الأكثر شيوعًا في بياناته، لا بالأفضل.

أثبت Zhang et al. (ACL 2025) أن 7 نماذج LLM تُفضّل بشكل منهجي مزودين بعينهم دون تعليمات صريحة، وتُعدّل الكود تلقائيًا لإدراج المزود المفضّل. المستخدم يظن أن ما أوصى به الذكاء الاصطناعي هو الأفضل، والذكاء الاصطناعي يوصي بالأكثر تكرارًا في بيانات التدريب. هذا هو تحيز المداهنة في نسخته البنية التحتية.

حين يختبئ المنطق في الصندوق الأسود

المشكلة الحقيقية في Supabase ليست Supabase نفسه. المشكلة هي أن منطق الأعمال يدخل إلى داخل الصندوق الأسود.

1. سياسات RLS = منطق أعمال مخفي

Row Level Security ميزة قوية. لكن المشكلة هي: حين ينشئ الذكاء الاصطناعي سياسات RLS، أين تسكن؟

• ليست في الكود. بل في لوحة تحكم Supabase.
• ليست في git. لا يوجد تحكم بالإصدارات.
• ليست في الاختبارات. لا يمكن التحقق منها في CI.

سؤال “من يمكنه الوصول إلى هذا الجدول؟” لا تجد إجابته في قاعدة الكود. يجب عليك تسجيل الدخول إلى وحدة تحكم Supabase للتحقق. الوكيل لا يستطيع قراءة هذا.

إذا عدّل الذكاء الاصطناعي سياسات RLS بحجة “التنظيم”؟ ينكسر نظام المصادقة. لا اختبارات، لا أحد يعرف. يُكتشف الأمر فقط بعد تسرّب بيانات العملاء في الإنتاج.

هذا ليس افتراضًا. في عام 2025، CVE-2025-48757 كشفت أن أكثر من 170 تطبيقًا أنشأه Lovable كانت قواعد بياناتها في Supabase مكشوفة بالكامل بسبب سياسات RLS المفقودة. 303 نقطة نهاية ضعيفة، وتسرّب عناوين البريد الإلكتروني ومفاتيح API ومعلومات الدفع. وفي يناير 2026، نُشر الشبكة الاجتماعية Moltbook بـ RLS معطّل، مما أسفر عن كشف 1.5 مليون رمز API و35,000 بريد إلكتروني.

2. Edge Functions = الصندوق الأسود الثاني

منطق الأعمال يعيش في مكانين: كود الواجهة الأمامية وـ Supabase Edge Functions. الذكاء الاصطناعي يجب أن يقرر أي منطق في أي مكان. والذكاء الاصطناعي يُخطئ في هذا القرار.

حساب خصم الدفع في Edge Function. الذكاء الاصطناعي يعيد هيكلة الواجهة الأمامية وينشئ الحساب ذاته فيها مجددًا. الآن يُطبَّق الخصم مرتين. يُكتشف بعد 3 أسابيع في تقرير المبيعات.

3. الترحيل = تكلفة الخروج

للمغادرة من Supabase، عليك تفكيك أربعة أشياء في آنٍ واحد:

1. Auth — هيكل JWT المقيّد بـ Supabase Auth، ورد اتصالات OAuth، وإدارة الجلسات
2. Storage — هيكل الحاويات، وسياسات الوصول، وتوقيع الروابط
3. Realtime — اشتراكات WebSocket، وقنوات Presence
4. سياسات RLS — جميع قواعد الأعمال غير الموثّقة

كل واحدة تبدو وكأنها تستغرق يومًا، لكن الأربعة متشابكة مع بعضها. تغيير Auth يكسر RLS، وكسر RLS يفتح وصول Storage، وتغيير روابط Storage يكسر الواجهة الأمامية.

هذا هو vendor lock-in. الدخول يستغرق 30 ثانية، والخروج يستغرق 3 أشهر.

نسخة السحابة من جحيم المنافذ

جحيم المنافذ الذي يعيشه المبرمج الارتجالي محليًا — الذكاء الاصطناعي يُشغّل خادمًا ولا يوقفه، والمنافذ تتشابك، ولا أحد يعرف ما الذي يعمل — هذا يرتفع في Supabase إلى مستوى البنية التحتية.

جحيم المنافذ المحلي: العمليات غير مرئية. جحيم Supabase: منطق الأعمال غير مرئي.

الاثنان لهما نفس البنية. ما يصنعه الوكيل لا يستطيع الوكيل تتبّعه.

ما هو البديل؟

لا يُقال هنا لا تستخدم Supabase. يُقال لا تضع منطق أعمالك في الصندوق الأسود.

المبدأ: كل قرار يجب أن يعيش في قاعدة الكود.

• قواعد المصادقة ← معلنة في الكود، مُتحقَّق منها بالاختبارات
• سياسات الوصول ← معلنة بـ DDL + Rego، مُتحقَّق منها في CI
• منطق الأعمال ← موجود في مكان واحد فقط، بلا تكرار
• إعدادات البنية التحتية ← معلنة بـ Terraform/IaC، مُصدَّرة في git

استخدام Supabase للنماذج الأولية أمر معقول. لكن لحظة نقل النموذج الأولي إلى الإنتاج، يجب استخراج المنطق من الصندوق الأسود ونقله إلى طبقة تصريحية.

لكي لا تتحوّل سحر الثلاثين ثانية إلى ثلاثة أشهر من المعاناة.

هل سياسات RLS الخاصة بك موجودة في git؟

هل Edge Functions الخاصة بك مُختبَرة؟

هل أنت متأكد أن “تنظيم” الذكاء الاصطناعي لن يكسر المصادقة؟

Supabase ليس المشكلة. المشكلة هي إخفاء القرارات في أماكن لا تُرى.

مقالات ذات صلة

• Reins Engineering — الذكاء الاصطناعي بلجام — الجانب المقابل للصندوق الأسود. توجيه الوكيل بعقود حتمية.
• AI أعمال الاصطناعي هي ميزة تجارية — آلية توصية الذكاء الاصطناعي بـ Supabase. الرأي يجلب المداهنة، والحقيقة تجلب التصحيح.
• قاعدة كود يستطيع الوكيل العمل فيها — واجهة لوحة التحكم لا يستطيع الوكيل قراءتها أو التحقق منها أو الاستمرار فيها. قاعدة الكود يجب أن تكون المصنع.
• yongol — عمود فقري SaaS للبرمجة بالذكاء الاصطناعي — بديل الصندوق الأسود. إعلان القرارات بشكل تصريحي في 10 مصادر SSOT والتحقق منها تبادليًا.

المصادر

• Zhang, Y. et al. (2025). “The Invisible Hand: Unveiling Provider Bias in Large Language Models for Code Generation.” ACL 2025. arxiv.org/abs/2501.07849
• CVE-2025-48757 (2025). Lovable 생성 앱 170+ RLS 누락으로 Supabase DB 노출. ameeba.com
• OG William (2026). “Moltbook Hack: Supabase Vibe Coding.” 1.5M API 토큰 + 35K 이메일 노출. blog.ogwilliam.com
• Willison, S. (2025). “Supabase MCP can leak your entire SQL database.” simonwillison.net
• Cursino, D. et al. (2026). “Speed at the Cost of Quality? The Impact of AI Coding on Software.” MSR 2026. arxiv.org/abs/2511.04427
• Storey, M.-A. (2026). “From Technical Debt to Cognitive and Intent Debt.” arxiv.org/abs/2603.22106
• Encore (2026). “Backend as a Service (BaaS) in 2026: Providers, Tradeoffs, and Migration Paths.” encore.dev