ຜົນກະທົບ
ຄວາມລົ້ມເຫລວໃນການປະຕິບັດຄວາມປອດໄພລະດັບແຖວ (RLS) ອະນຸຍາດໃຫ້ຜູ້ໂຈມຕີທີ່ບໍ່ໄດ້ຮັບຄວາມຖືກຕ້ອງສອບຖາມຂໍ້ມູນຈາກຖານຂໍ້ມູນ Supabase ເມື່ອຕາຕະລາງສາທາລະນະຖືກເປີດເຜີຍຜ່ານເຂດແດນ anon [S1]. ເນື່ອງຈາກແອັບພລິເຄຊັນ Next.js ໂດຍທົ່ວໄປຈະເປີດເຜີຍລະຫັດ Supabase anon ໃນລະຫັດຂ້າງລູກຄ້າ, ຜູ້ໂຈມຕີສາມາດໃຊ້ກະແຈນີ້ເພື່ອເຮັດໃຫ້ການໂທ REST API ໂດຍກົງໄປຫາຖານຂໍ້ມູນ, ຂ້າມການເຂົ້າເຖິງຂໍ້ມູນຜູ້ໃຊ້ທີ່ລະອຽດອ່ອນຂອງແອັບພລິເຄຊັນ. [S2].
ສາເຫດ
ໂດຍຄ່າເລີ່ມຕົ້ນ, ຕາຕະລາງ Postgres ໃນ Supabase ຕ້ອງການການເປີດໃຊ້ Row Level Security ຢ່າງຈະແຈ້ງເພື່ອປ້ອງກັນການເຂົ້າເຖິງສາທາລະນະ [S1]. ເມື່ອຜູ້ພັດທະນາສ້າງຕາຕະລາງແຕ່ລືມເປີດໃຊ້ RLS ຫຼືບໍ່ກໍານົດນະໂຍບາຍຈໍາກັດ, ຖານຂໍ້ມູນອາດຈະເປີດເຜີຍຂໍ້ມູນໃຫ້ກັບໃຜທີ່ມີລະຫັດ anon ຂອງໂຄງການ [S1]. ໃນແອັບພລິເຄຊັນ Next.js, ການສະແດງຜົນຂ້າງເຊີບເວີ ແລະການດຶງຂໍ້ມູນຂ້າງລູກຄ້າຍັງຕ້ອງການການຕິດຕັ້ງລູກຄ້າ Supabase ຢ່າງລະອຽດເພື່ອໃຫ້ບໍລິບົດຜູ້ໃຊ້ທີ່ກວດສອບຄວາມຖືກຕ້ອງໄປຮອດຊັ້ນຖານຂໍ້ມູນ [S2].
ແກ້ໄຂຄອນກີດ
- ເປີດໃຊ້ RLS: ປະຕິບັດ
ALTER TABLE "your_table_name" ENABLE ROW LEVEL SECURITY;ສໍາລັບທຸກໆຕາຕະລາງສາທາລະນະທີ່ເກັບຂໍ້ມູນແອັບຯ [S1]. - ກຳນົດນະໂຍບາຍ: ສ້າງນະໂຍບາຍສະເພາະທີ່ຈຳກັດການເຂົ້າເຖິງໂດຍອີງໃສ່ສະຖານະການກວດສອບຜູ້ໃຊ້, ເຊັ່ນ
CREATE POLICY "Users can see their own data" ON your_table_name FOR SELECT USING (auth.uid() = user_id);[S1]. - ລູກຄ້າຂ້າງເຊີບເວີທີ່ປອດໄພ: ເມື່ອໃຊ້ Next.js, ຮັກສາບົດບາດລູກຄ້າຂອງເຊີບເວີເທົ່ານັ້ນ ແລະຍັງນຳໃຊ້ຕົວກອງຄວາມເປັນເຈົ້າຂອງກ່ອນທີ່ຈະສົ່ງຄືນຂໍ້ມູນໃຫ້ກັບຜູ້ໃຊ້ [S2].
ວິທີການ FixVibe ທົດສອບສໍາລັບມັນ
FixVibe ແລ້ວແລ່ນ Supabase RLS ທີ່ອ່ານຢ່າງດຽວແລ້ວກວດເບິ່ງຜ່ານ baas.supabase-rls. ເຄື່ອງສະແກນຄົ້ນພົບ URL ໂຄງການ Supabase ແລະລະຫັດ anon ສາທາລະນະຈາກຊຸດ JavaScript ຕົ້ນສະບັບດຽວກັນ, ຖາມ PostgREST ສໍາລັບ metadata ຕາຕະລາງສາທາລະນະ, ແລະພະຍາຍາມຈໍາກັດພຽງແຕ່ເລືອກເພື່ອຢືນຢັນວ່າຂໍ້ມູນຖືກເປີດເຜີຍໂດຍບໍ່ມີເຊດຊັນຜູ້ໃຊ້. ມັນບໍ່ໃສ່, ປັບປຸງ, ລຶບ, ຫຼືໃຊ້ຂໍ້ມູນປະຈໍາຕົວຂອງການບໍລິການ. ການສະແກນ Repo ຍັງສາມາດຈັບໄດ້ກ່ອນຫນ້ານີ້ໂດຍຜ່ານ repo.supabase.missing-rls, ເຊິ່ງຊີ້ໃຫ້ເຫັນການເຄື່ອນຍ້າຍ SQL ທີ່ສ້າງຕາຕະລາງສາທາລະນະໂດຍບໍ່ມີ ENABLE ROW LEVEL SECURITY.