إذا منتجك مبني بـ Lovable أو Bolt أو v0 على Supabase، المتصفح يكلّم قاعدة البيانات مباشرة بمفتاح عام موجود في كود منتجك. اللي يحمي بيانات عملائك هو قواعد RLS على كل جدول. جدول بدون RLS، أو بقاعدة شرطها true، يقدر أي أحد يقرأه. هذا اللي كشف بيانات منتجات كثيرة في ثغرة Lovable.
1. انسخ الاستعلام وشغّله في مشروعك
افتح مشروعك في لوحة Supabase، ثم SQL Editor، والصق هذا الاستعلام واضغط Run. يقرأ وصف الجداول فقط، وما يقرأ أي بيانات.
-- Muhandis RLS check: reads table descriptions only, never a row.
select json_build_object(
'tool', 'muhandis-rls-check',
'v', 1,
'tables', coalesce((
select json_agg(t order by t.name)
from (
select
c.relname as name,
case c.relkind when 'v' then 'view' when 'm' then 'view' else 'table' end as kind,
c.relrowsecurity as rls,
coalesce((
select json_agg(a.attname order by a.attnum)
from pg_attribute a
where a.attrelid = c.oid and a.attnum > 0 and not a.attisdropped
), '[]'::json) as columns,
coalesce(c.reloptions::text like '%security_invoker=true%' or c.reloptions::text like '%security_invoker=on%', false) as invoker,
coalesce((
select json_agg(distinct g.grantee || ':' || g.privilege_type)
from information_schema.role_table_grants g
where g.table_schema = 'public' and g.table_name = c.relname and g.grantee in ('anon', 'authenticated', 'PUBLIC')
), '[]'::json) as grants,
coalesce((
select json_agg(json_build_object('cmd', p.cmd, 'roles', p.roles, 'using', p.qual, 'check', p.with_check, 'permissive', p.permissive))
from pg_policies p
where p.schemaname = 'public' and p.tablename = c.relname
), '[]'::json) as policies
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
where n.nspname = 'public' and c.relkind in ('r', 'p', 'v', 'm')
) t
), '[]'::json)
) as result;
لقيت جداول مكشوفة؟
صلّحها قبل أي شي ثاني. إذا الجداول كثيرة أو ما تدري من وين تبدأ، تدقيق جاهزية الإطلاق يمر عليها كلها ويعطيك تقرير مكتوب بالأولويات. شوف إيش فيه التدقيق
بدون أي كلمة سر · تقدر تلغي خلال 7 أيام من الدفع قبل لا نبدأ
إيش يعني كل لون
مكشوف: RLS مطفي والزوار لهم صلاحية، أو قاعدة شرطها true على جدول فيه بيانات أشخاص، أو أي مستخدم يعدّل أو يحذف سطور غيره، أو view يتجاوز RLS. صلّحه اليوم.
تأكد منه: مفتوح للكل، وهذا مقبول فقط إذا البيانات عامة فعلًا، مثل قائمة منتجات أو نموذج تواصل.
مقفول: التطبيق ما يقرأ الجدول أصلًا. إذا منتجك يحتاجه، أضف قاعدة قبل ما تعطي الصلاحية.
سليم: القواعد مربوطة بصاحب السطر، أو الـ view يطبّق RLS.
ليش الفحص آمن
ما نطلب رابط مشروعك ولا مفاتيحه. أي أداة تفحص منتجك «من برا» تقدر تفحص منتجات الناس الثانية بنفس الطريقة، لأن المفتاح العام موجود في كود كل منتج. هنا الاستعلام يشتغل داخل لوحتك أنت، ويقرأ وصف الجداول فقط، والنتيجة تنقرأ في متصفحك.
لا. الاستعلام يقرأ وصف الجداول فقط: أسماءها، وهل RLS مفعّل، وقواعدها، ومين له صلاحية عليها. وتشغّله أنت في لوحة Supabase حقتك، والنتيجة تنقرأ داخل متصفحك وما تنرسل لأي مكان.
يعدّل شي في قاعدة بياناتي؟
لا. هو استعلام قراءة فقط (select)، ما يضيف ولا يعدّل ولا يحذف شي.
منتجي على Lovable Cloud وما عندي لوحة Supabase؟
شغّل نفس الاستعلام من داخل Lovable: افتح مشروعك، ثم تبويب Cloud، ثم SQL editor. والصق النتيجة هنا مثل أي مشروع ثاني. وخلّ فحص Security في Lovable شغّال بعد، وجرّب منتجك بحسابين: كل حساب لازم يشوف بياناته فقط.
إذا طلعت النتيجة كلها خضراء، منتجي آمن؟
يعني ما لقينا قاعدة مفتوحة للكل، وهذا أهم شي. لكنه فحص للقواعد الظاهرة: قاعدة شرطها غلط بطريقة ثانية ما تبان إلا بالتجربة. جرّب بحسابين، ومر على قائمة التحقق قبل الإطلاق. والفحص يقرأ جداول public فقط: ملفات Storage والدوال ما يشملها.