A Next.js + Supabase biztosítása: Sorszintű biztonság (RLS) megkerülésének megakadályozása

Hatás

A támadók megkerülhetik az alkalmazáslogikát az adatbázis rekordjainak olvasásához, frissítéséhez vagy törléséhez, ha a sorszintű biztonság (RLS) nincs megfelelően kényszerítve: [S1]. Ez gyakran azt eredményezi, hogy személyazonosításra alkalmas adatok (PII) vagy érzékeny alkalmazásadatok kerülnek olyan felhasználók elé, akik csak a nyilvános, névtelen API kulcshoz férnek hozzá.

Kiváltó ok

A Supabase a Postgres Row Level Security segítségével kezeli az adathozzáférést az adatbázis szintjén, ami alapvető fontosságú a [S1] adatok biztonságához. Next.js környezetben a fejlesztőknek létre kell hozniuk egy Supabase klienst, amely megfelelően kezeli a cookie-kat és a munkameneteket, hogy fenntartsa a biztonságot a [S2] szerveroldali renderelés során. A sebezhetőségek általában akkor merülnek fel, ha:

• A táblázatok a RLS engedélyezése nélkül jönnek létre, így a [S1] nyilvános anonkulccsal érhetők el.
• A Supabase ügyfél rosszul van konfigurálva a Next.js fájlban, és nem tudja megfelelően átadni a felhasználói hitelesítési tokeneket a [S2] adatbázisnak.
• A fejlesztők véletlenül a service_role kulcsot használják az ügyféloldali kódban, amely megkerül minden RLS [S1] házirendet.

Konkrét javítások

• A RLS engedélyezése: Győződjön meg arról, hogy a sorszintű biztonság engedélyezve van a Supabase [S1] adatbázisában található minden táblánál.
• Határozza meg a házirendeket: Hozzon létre specifikus Postgres-házirendeket a SELECT, INSERT, UPDATE és DELETE műveletekhez, hogy korlátozza a hozzáférést a felhasználó ZBETCEN4XVIXF azonosítója alapján.
• SSR-kliensek használata: A @supabase/ssr csomag megvalósításával olyan ügyfeleket hozhat létre a Next.js-ben, amelyek megfelelően kezelik a kiszolgálóoldali hitelesítést és a munkamenet-megmaradást [S2].

Hogyan teszteli a FixVibe

A FixVibe ezt már lefedi a telepített alkalmazások és a repoellenőrzések révén. A passzív baas.supabase-rls modul felfedezi a Supabase URL-címet és a névtelen kulcspárokat az azonos eredetű JavaScript-kötegekből, nyilvános tábla metaadatokat kér a PostgREST-től, és korlátozott, csak olvasható kiválasztásokat hajt végre az anonim adatok megjelenítésének megerősítése érdekében az ügyféladatok mutációja nélkül. A repo-ellenőrzések a repo.supabase.missing-rls fájlt is futtatják, hogy megjelöljék azokat az SQL-migrációkat, amelyek nyilvános táblákat hoznak létre ENABLE ROW LEVEL SECURITY nélkül, a titkos vizsgálatok pedig a szolgáltatási szerepkör kulcsának megtekintését keresik, mielőtt az elérné a böngészőt.