Ang kawit
Ang pag-secure ng proyektong Supabase ay nangangailangan ng multi-layered na diskarte na nakatuon sa API key management, database security, at mga pahintulot sa storage. [S1] Ang hindi wastong na-configure na Row Level Security (RLS) o nakalantad na mga sensitibong key ay maaaring humantong sa mga makabuluhang insidente ng pagkakalantad ng data. [S2] [S3]
Ano ang nagbago
Pinagsasama-sama ng pananaliksik na ito ang mga pangunahing kontrol sa seguridad para sa mga kapaligiran ng Supabase batay sa mga opisyal na alituntunin sa arkitektura. [S1] Nakatuon ito sa paglipat mula sa mga default na configuration ng development tungo sa production-hardened postures, partikular tungkol sa mga mekanismo ng access control. [S2] [S3]
Sino ang apektado
Apektado ang mga application na gumagamit ng Supabase bilang Backend-as-a-Service (BaaS), lalo na ang mga humahawak ng data na partikular sa user o mga pribadong asset. [S2] Ang mga developer na kasama ang service_role key sa mga bundle sa panig ng kliyente o hindi na-enable ang RLS ay nasa mataas na panganib. [S1]
Paano gumagana ang isyu
Ginagamit ng Supabase ang Row Level Security ng PostgreSQL upang paghigpitan ang pag-access ng data. [S2] Bilang default, kung ang RLS ay hindi pinagana sa isang talahanayan, sinumang user na may anon key—na kadalasang pampubliko—ay maa-access ang lahat ng record. [S1] Katulad nito, ang Supabase Storage ay nangangailangan ng tahasang mga patakaran upang tukuyin kung aling mga user o tungkulin ang maaaring magsagawa ng mga operasyon sa mga file bucket. [S3]
Ano ang nakukuha ng isang umaatake
Maaaring gamitin ng isang attacker na may pampublikong API key ang mga talahanayang nawawalang RLS upang basahin, baguhin, o tanggalin ang data na pagmamay-ari ng ibang mga user. [S1] [S2] Ang hindi awtorisadong pag-access sa mga storage bucket ay maaaring humantong sa pagkakalantad ng mga file ng pribadong user o ang pagtanggal ng mga kritikal na asset ng application. [S3]
Paano sinusuri ito ng FixVibe
Sinasaklaw na ito ngayon ng FixVibe bilang bahagi ng mga pagsusuri sa Supabase nito. Sinusuri ng baas.supabase-security-checklist-backfill ang pampublikong Supabase Storage bucket metadata, anonymous object-listing exposure, sensitibong pangalan ng bucket, at anon-bound na mga signal ng Storage mula sa public anon boundary. Sinusuri ng mga nauugnay na live na pagsusuri ang pagkakalantad ng pangunahing tungkulin ng serbisyo, Supabase REST/RLS posture, at mga paglilipat ng SQL ng repository para sa nawawalang RLS.
Ano ang dapat ayusin
Palaging paganahin ang Row Level Security sa mga talahanayan ng database at ipatupad ang mga granular na patakaran para sa mga na-authenticate na user. [S2] Tiyakin na ang 'anon' na key lamang ang ginagamit sa client-side code, habang ang 'service_role' na key ay nananatili sa server. [S1] I-configure ang Storage Access Control upang matiyak na ang mga file bucket ay pribado bilang default at ang access ay ibinibigay lamang sa pamamagitan ng tinukoy na mga patakaran sa seguridad. [S3]