اثر
حملو ڪندڙ ڊيٽابيس ۾ رڪارڊ پڙهڻ، تازه ڪاري ڪرڻ يا حذف ڪرڻ لاءِ ايپليڪيشن جي منطق کي نظرانداز ڪري سگھن ٿا جيڪڏهن قطار ليول سيڪيورٽي (RLS) [S1] صحيح طريقي سان لاڳو نه ڪئي وئي آهي. اهو اڪثر ڪري ذاتي طور تي سڃاڻپ جي قابل معلومات (PII) يا حساس ايپليڪيشن ڊيٽا جي نمائش ۾ نتيجو آهي صارفين کي جن کي صرف عوامي گمنام API ڪي تائين رسائي آهي.
بنيادي سبب
Supabase ڊيٽابيس جي سطح تي ڊيٽا جي رسائي کي منظم ڪرڻ لاءِ Postgres Row Level Security استعمال ڪري ٿو، جيڪو [S1] ڊيٽا کي محفوظ ڪرڻ لاءِ بنيادي آهي. Next.js ماحول ۾، ڊولپرز کي لازمي طور تي ھڪڙو Supabase ڪلائنٽ ٺاھيو وڃي ٿو جيڪو صحيح طريقي سان ڪوڪيز ۽ سيشن کي سنڀالي ٿو ته جيئن سرور-سائڊ رينجرنگ [S2] دوران سيڪيورٽي برقرار رکي. ڪمزوريون عام طور تي پيدا ٿينديون آهن جڏهن:
- RLS فعال ٿيڻ کان سواءِ ٽيبلز ٺاهيا ويا آهن، انهن کي عوامي اينان ڪيئي [S1] ذريعي رسائي لائق بڻائي ٿو.
- Supabase ڪلائنٽ Next.js ۾ غلط ترتيب ڏنل آهي، ڊيٽابيس [S2] کي صحيح طور تي صارف جي تصديق واري ٽوڪن کي منتقل ڪرڻ ۾ ناڪام ٿي.
- ڊولپرز غلط طور تي استعمال ڪن ٿا
service_roleڪلائنٽ سائڊ ڪوڊ ۾، جيڪو سڀني RLS پاليسين کي نظرانداز ڪري ٿو [S1].
ڪنڪريٽ فيڪس
- RLS کي فعال ڪريو: پڪ ڪريو ته قطار ليول سيڪيورٽي توهان جي Supabase ڊيٽابيس [S1] ۾ هر ٽيبل لاءِ فعال آهي.
- پاليسيون بيان ڪريو:
SELECT،INSERT،UPDATE، ۽DELETEلاءِ مخصوص پوسٽ گريس پاليسيون ٺاهيون ته يوزر جي رسائي کي محدود ڪرڻ لاءِ. [S1]. - SSR ڪلائنٽ استعمال ڪريو:
@supabase/ssrپئڪيج کي Next.js ۾ ڪلائنٽ ٺاهڻ لاءِ لاڳو ڪريو جيڪي سرور جي طرف جي تصديق ۽ سيشن جي تسلسل کي صحيح طريقي سان منظم ڪن [S2].
ڪيئن FixVibe ان لاءِ ٽيسٽ ڪري ٿو
FixVibe اڳ ۾ ئي شامل ڪري ٿو هن کي ترتيب ڏنل ايپ ۽ ريپو چيڪن ذريعي. غير فعال baas.supabase-rls ماڊل دريافت ڪري ٿو Supabase URL ۽ ساڳئي-اصل جاوا اسڪرپٽ بنڊلن مان anon-key جوڙا، عوامي ٽيبل ميٽا ڊيٽا لاءِ PostgREST کان پڇي ٿو، ۽ گمنام ڊيٽا جي نمائش جي تصديق ڪرڻ لاءِ محدود صرف پڙهڻ لاءِ چونڊون انجام ڏئي ٿو. ريپو اسڪين پڻ هلائيندا آهن repo.supabase.missing-rls کي پرچم ڪرڻ لاءِ SQL لڏپلاڻ جيڪي ENABLE ROW LEVEL SECURITY کان سواءِ عوامي ٽيبل ٺاهيندا آهن، ۽ ڳجهي اسڪين برائوزر تائين پهچڻ کان اڳ سروس جي ڪردار جي اهم نمائش کي ڳوليندا آهن.