أمان مستوى الصف في Supabase: 7 أخطاء ترتكبها التطبيقات المبنية بالذكاء الاصطناعي

إذا بُني تطبيقك باستخدام Lovable أو Bolt أو أداة بناء مماثلة بالذكاء الاصطناعي، فاحتمال كبير أنه يستخدم Supabase لقاعدة البيانات وتسجيل الدخول. وهذا خيار منطقي. لكنه يعني أيضاً أن إعداداً واحداً يحدد ما إذا كانت بيانات عملائك خاصة أم عامة: Row Level Security، ويُختصر عادةً إلى RLS.

أفاد باحثون أمنيون علناً في عام 2025 بأن عدداً كبيراً من التطبيقات التي أنشأتها إحدى أدوات البناء الشهيرة بالذكاء الاصطناعي كشف بيانات المستخدمين لأن سياسات RLS كانت مفقودة أو ضعيفة جداً. وقد عملت التطبيقات بشكل مثالي أثناء الاختبار، لأن المطوّر والمالك يستطيعان دائماً رؤية كل شيء. ولا تظهر المشكلة إلا حين يطلب مستخدم آخر، أو مهاجم، بيانات ليست له.

يشرح هذا الدليل RLS بعبارات بسيطة، ثم يستعرض الأخطاء السبعة الأكثر شيوعاً في مشاريع Supabase المولَّدة بالذكاء الاصطناعي، مع الحل لكل منها.

RLS بعبارات بسيطة

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

Row Level Security هي كتاب القواعد هذا. تحدد كل قاعدة (سياسة) أي الصفوف يجوز لنوع معين من المستخدمين قراءتها أو إدراجها أو تحديثها أو حذفها. ومن القواعد النموذجية: «يستطيع المستخدم المسجّل قراءة الصفوف التي يساوي فيها user_id معرّفه الخاص». وإذا كانت RLS معطلة لجدول ما، أو كانت السياسات سخية أكثر من اللازم، فلن يُطبَّق كتاب القواعد وستجيب API أي شخص.

الخطأ 1: لم يتم تفعيل RLS قط

الجداول المنشأة عبر SQL أو ملفات الترحيل غير محمية حتى تفعّل RLS عليها. وغالباً ما تنشئ أدوات الذكاء الاصطناعي الجداول وتبني الشاشات ثم تنتقل إلى غيرها. ويعمل كل شيء لأنه لا توجد أي قيود على الإطلاق.

للتحقق، شغّل الاستعلام التالي في محرر SQL في Supabase وابحث عن أي جدول في المخطط public تكون فيه قيمة rowsecurity تساوي false:

select schemaname, tablename, rowsecurity
from pg_tables
where schemaname = 'public';

فعّلها بسطر واحد لكل جدول، ثم أضف السياسات. تفعيل RLS دون سياسات يحجب كل شيء، وهذا هو الوضع الافتراضي الآمن الذي تنطلق منه:

alter table public.invoices enable row level security;

تتضمن لوحة تحكم Supabase أيضاً Security Advisor الذي ينبّه إلى الجداول التي لا تملك RLS. شغّله قبل كل إطلاق.

الخطأ 2: سياسات تسمح بكل شيء

عندما تصطدم أداة الذكاء الاصطناعي بخطأ «permission denied»، فإن أحد الاختصارات الشائعة سياسة مثل using (true). فهي تُخفي الخطأ وتجعل البيانات عامة في اللحظة نفسها.

-- Looks harmless, exposes every row to every user:
create policy "Allow read" on public.invoices
for select using (true);

استبدلها بقاعدة مرتبطة بالمستخدم المسجّل:

create policy "Users can read their own invoices"
on public.invoices for select
to authenticated
using ( (select auth.uid()) = user_id );

يمكن للبيانات العامة فعلاً، مثل كتالوج المنتجات، استخدام سياسة قراءة مفتوحة. أما أي بيانات شخصية أو مالية أو خاصة فلا يجوز ذلك.

الخطأ 3: مفتاح الخدمة مكشوف

لدى Supabase مفتاحان مهمان. مفتاح anon مخصص للمتصفحات ويعتمد على RLS. أما مفتاح دور الخدمة (service role) فيتجاوز RLS بالكامل. وإذا ظهر في شيفرة الواجهة الأمامية، أو في متغير يُضمَّن في الموقع، أو في مستودع عام، فكل سياسة كتبتها تصبح بلا قيمة.

ابحث عنه في JavaScript المبني وفي سجل Git. وإذا كُشف يوماً، فغيّره (rotate) فوراً من لوحة تحكم Supabase. مفاتيح الخدمة مكانها الوحيد شيفرة جهة الخادم، مثل دالة edge أو الواجهة الخلفية، وليس في أي شيء يحمّله المتصفح.

الخطأ 4: أدوار مخزّنة حيث يستطيع المستخدمون تعديلها

من الأنماط المتكررة وسم المسؤولين بحقل مثل role: "admin" داخل البيانات الوصفية للمستخدم، ثم التحقق منه في سياسة أو في الواجهة. وفي Supabase، يمكن للمستخدم المسجّل تغيير منطقة user_metadata. وبذلك يستطيع المستخدم منح نفسه علامة المسؤول ببساطة.

احتفظ ببيانات الصلاحيات في أماكن لا يستطيع المستخدمون الكتابة فيها: جدول أدوار مخصص تحميه RLS بدوره، أو app_metadata الذي يتحكم به الخادم. ثم ابنِ سياساتك على ذلك.

الخطأ 5: قواعد الإدراج والتحديث دون "with check"

تستطيع السياسة التحكم في الصفوف الموجودة التي يجوز لك لمسها (using) وفي القيم التي يجوز لك كتابتها (with check). وإذا غاب الجزء الثاني، يستطيع المستخدم إدراج صفوف تخص شخصاً آخر، أو تحديث صفه ليسلّمه إلى حساب آخر.

create policy "Users can insert their own invoices"
on public.invoices for insert
to authenticated
with check ( (select auth.uid()) = user_id );

create policy "Users can update their own invoices"
on public.invoices for update
to authenticated
using ( (select auth.uid()) = user_id )
with check ( (select auth.uid()) = user_id );

الخطأ 6: عروض ودوال تتجاوز القواعد

يعمل عرض قاعدة البيانات (view) افتراضياً بصلاحيات مالكه، مما قد يتجاوز RLS على الجداول الأساسية. وفي Postgres 15 وما بعده يمكنك جعل العرض يحترم صلاحيات المستدعي باستخدام security_invoker = true. وبالمثل، فإن الدالة المعلَّمة بـ security definer والمكشوفة عبر API تعمل بصلاحيات مرتفعة، لذا يجب أن تتحقق من هوية المستدعي وأن تثبّت search_path الخاص بها.

العروض والدوال "المساعدة" المولَّدة بالذكاء الاصطناعي للوحات التحكم مصدر شائع لهذه المشكلة. راجع كلاً منها واسأل: بصلاحيات من يعمل هذا؟

الخطأ 7: مجموعات التخزين وثغرات تعدد المستأجرين

للملفات قواعدها الخاصة المنفصلة عن قواعد الجداول. المجموعة العامة (public bucket) تقدّم الملفات لأي شخص يملك الرابط، وهذا مناسب للشعارات وغير مناسب للعقود. وللملفات الخاصة، نظّم عمليات الرفع بحسب المستخدم أو المستأجر واكتب سياسات التخزين لتطابقها، مثلاً باشتراط أن يساوي أول مجلد في المسار معرّف المستخدم:

create policy "Users can read their own files"
on storage.objects for select
to authenticated
using (
  bucket_id = 'documents'
  and (storage.foldername(name))[1] = (select auth.uid()::text)
);

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

كيف تختبر تطبيقك بنفسك في 15 دقيقة

1. اختبار مجهول. استدعِ نقاط نهاية جداولك باستخدام مفتاح anon العام فقط ودون تسجيل دخول. يجب أن تعيد الجداول الخاصة لا شيء أو خطأ.
2. اختبار الحسابين. أنشئ مستخدمين ببيانات منفصلة. بصفتك المستخدم B، حاول قراءة سجلات المستخدم A وتعديلها وحذفها بتغيير المعرّفات في الطلبات.
3. اختبار الصلاحيات. بصفتك مستخدماً عادياً، جرّب ميزات الإدارة مباشرة، وحاول تغيير دورك بنفسك.
4. شغّل Security Advisor وأصلح كل تحذير يتعلق بـ RLS.
5. احتفظ بالاختبارات. يدعم Supabase اختبارات قاعدة البيانات الآلية، حتى لا يعيد تغيير مستقبلي فتح الثغرة بهدوء.

إذا كنت قد أطلقت التطبيق بالفعل

فعّل RLS وأصلح السياسات أولاً، ثم غيّر أي مفاتيح مكشوفة. افحص سجلاتك بحثاً عن وصول غير معتاد. وإذا كانت البيانات الشخصية لمستخدمين حقيقيين قد انكشفت، فقد تترتب عليك التزامات قانونية بإبلاغهم بحسب أماكن إقامتهم، لذا استشر محامياً. وإصلاح قواعد الوصول سريع عادةً. أما معرفة ما حدث وما يجب الإفصاح عنه فيستغرق وقتاً أطول، وهذا سبب إضافي لاكتشاف هذه المشكلات قبل الإطلاق.

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