ماسح Supabase RLS: ابحث عن الجداول التي تفتقر إلى أمان مستوى الصف أو يعاني من خلل

ما يستطيع مسح RLS خارجي إثباته

A passive RLS scan looks at your Supabase project the way an anonymous visitor would. It uses only the publishable anon key — the same key your browser uses — and never authenticates as a user or touches service-role privileges. Anything it can see, an unauthenticated attacker on the internet can see.

من خارج قاعدة البيانات، يمكن للماسح أن يؤكد ما يلي بثقة عالية:

• RLS معطّل على جدول. يُرجع PostgREST صفوفًا لاستعلام SELECT مجهول عند إيقاف تشغيل RLS أو عندما تسمح به سياسة. كلا الحالتين نتيجة.
• يمكن للدور المجهول إدراج الجداول. يُرجع طلب GET /rest/v1/ باستخدام مفتاح anon مخطط OpenAPI لكل جدول يملك الدور anon أي امتياز عليه. كثيرًا ما تمنح التطبيقات المُولَّدة بالذكاء الاصطناعي USAGE على المخطط وSELECT على كل جدول، مما يكشف خريطة المخطط الكاملة حتى عندما يرفض RLS القراءات الفعلية.
• Read access does not establish write safety. A passive scan cannot prove that INSERT, UPDATE, or DELETE policies protect every user and tenant. Review write policies and test them with isolated fixtures under the intended roles.
• مفتاح service-role موجود في حزمة المتصفح. بجوار RLS: إذا وجد الماسح SUPABASE_SERVICE_ROLE_KEY أو أي JWT يحتوي على role: service_role في حزمة JavaScript، يصبح RLS بلا قيمة — حامل ذلك المفتاح يتجاوز كل سياسة.

ما لا يستطيع المسح الخارجي إثباته

كن صادقًا بشأن حدود الماسح. لا يستطيع مسح RLS خارجي قراءة جدول pg_policies أو ملفات الهجرة أو المسند الدقيق لأي سياسة. يستنتج من السلوك في الصندوق الأسود، مما يعني أنه سيُبلِّغ أحيانًا عن نتيجة تتضح أنها بيانات عامة مقصودة (جدول لنشرة تسويقية، كتالوج منتجات عام). يُؤشِّر تقرير FixVibe هذه الحالات بـ ثقة متوسطة عندما لا يستطيع الماسح التمييز في النوايا — راجع اسم الجدول واتخذ القرار.

الأشكال الأربعة لـ RLS المعطّل التي تُنتجها أدوات الذكاء الاصطناعي

When you point Cursor, Claude Code, Lovable, or Bolt at Supabase, the same four broken-RLS patterns come up again and again. Each one passes type-check, compiles, and ships:

الشكل 1: لم يتم تفعيل RLS أصلًا

The most common failure mode. The migration creates the table but the developer (or the AI tool) forgets ALTER TABLE ... ENABLE ROW LEVEL SECURITY. PostgREST happily serves the entire table to anyone with the anon key. Fix: ALTER TABLE public.[name] ENABLE ROW LEVEL SECURITY;, then add a policy per command. Enabling RLS with no policies denies all access through the API; the policies decide who gets in.

ALTER TABLE public.[name] ENABLE ROW LEVEL SECURITY;

الشكل 2: RLS مُفعَّل ولكن بدون سياسات

فشل أكثر دقة. يكون RLS مُفعَّلًا ولكن لا تُكتب أي سياسات. الافتراضي في PostgreSQL هو الرفض، لذا لا يرى المستخدمون المُصادقون شيئًا — فيضيف المطور USING (true) لجعل التطبيق يعمل، مما يسمح للجميع بقراءة كل شيء. الإصلاح: اكتب سياسة محصورة بـ auth.uid(): CREATE POLICY "select_own" ON public.[name] FOR SELECT USING (auth.uid() = user_id); وسياسة INSERT/UPDATE/DELETE مطابقة.

CREATE POLICY "select_own"
  ON public.[name]
  FOR SELECT
  USING (auth.uid() = user_id);

الشكل 3: تقارن السياسة عمودًا بنفسه

أثر نسخ ولصق. يكتب المطور USING (user_id = user_id) — وهو دائمًا صحيح — بدلًا من USING (auth.uid() = user_id). يجتاز فحص النوع؛ تسمح السياسة بكل صف. الإصلاح: قارن دائمًا العمود باستدعاء دالة (auth.uid()، auth.jwt()->>'org_id'، إلخ)، وليس بنفسه أو بثابت.

Shape 4: Overly permissive write policies

With RLS enabled, a role with no applicable policy is denied by default. A SELECT policy does not itself allow INSERT. Write exposure can arise from a permissive applicable INSERT or ALL policy, disabled RLS, or a role that bypasses RLS. Fix: inspect table privileges and every applicable policy, use ownership-scoped WITH CHECK conditions, and test writes with separate user identities.

كيف يعمل ماسح Supabase RLS من FixVibe

FixVibe's Supabase check works from the deployed app, in three steps:

1. Find the project. FixVibe loads the deployed app and reads the Supabase project URL and public key from the same configuration your browser receives. No guessing, no brute force.
2. See what is exposed. FixVibe checks which tables the anonymous role can see, without reading row data at this step.
3. Stage 3 — inspect anonymous read access. The passive check reports observable access to discovered resources. It does not create, update, or delete database rows, and it cannot establish that all write policies or cross-user boundaries are correct.

Each finding ships with the exact request URL, response status, response shape (header-only), and the table name. FixVibe now labels whether the fix belongs in code/config, a provider console, DNS, secret rotation, or manual review so the next step matches who can actually apply it.

ماذا تفعل عندما يجد الماسح شيئًا

كل نتيجة RLS طارئة في وقت التشغيل. تتعرض نقاط نهاية PostgREST العامة لمسح المهاجمين خلال دقائق. تسلسل المعالجة آلي:

1. راجع كل جدول. شغِّل SELECT schemaname, tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public'; في محرر Supabase SQL. أي صف يحتوي على rowsecurity = false هو مشكلة.
2. Enable RLS on every public table. Default to ENABLE ROW LEVEL SECURITY on every table created — make it a migration template.
3. اكتب السياسات أمرًا بأمر. لا تستخدم FOR ALL USING (true). اكتب سياسات صريحة لـ SELECT وINSERT وUPDATE وDELETE — كل واحدة محصورة بـ auth.uid() أو عمود org-id من auth.jwt().
4. تحقق بحساب ثانٍ. سجِّل بحساب مستخدم آخر، وحاول قراءة سجلات مستخدم آخر عبر REST API مباشرة. إذا كانت الاستجابة 200، فالسياسة معطّلة.
5. Re-scan. After applying the fix, re-run a FixVibe scan against the same URL. The Supabase RLS finding should clear.

-- Audit every table for missing RLS. Run in the Supabase SQL editor.
SELECT schemaname, tablename, rowsecurity
FROM   pg_tables
WHERE  schemaname = 'public'
ORDER  BY rowsecurity, tablename;

كيف تُقارَن هذه الأداة بالماسحات الأخرى

معظم أدوات DAST العامة (Burp Suite وOWASP ZAP وNessus) لا تعرف ما هو PostgREST. ستزحف إلى تطبيقك، وتتجاهل المسار /rest/v1/، وتُبلِّغ عن صفحات HTML التي تفهمها. Snyk وSemgrep أدوات تحليل ساكن — تجد ملفات الهجرة في مستودعك حيث استدعاءات RLS مفقودة، ولكنها لا تستطيع إثبات أن قاعدة البيانات المنشورة مُهيَّأة بشكل خاطئ. يقع FixVibe في الفجوة: سلبي، مدرك لـ BaaS، يُركِّز على ما يستطيع مهاجم غير مصادق إثباته من عنوان URL العام.

الأسئلة الشائعة

الخطوات التالية

Run a free FixVibe scan against your production URL — the Supabase RLS check runs on every plan including the free tier. For a deeper read on what else can leak from a Supabase project, see Supabase service role key exposed in JavaScript and Supabase storage bucket security checklist. For the umbrella view across all BaaS providers, read BaaS misconfiguration scanner.