A horog
A Supabase projekt biztonságossá tétele többrétegű megközelítést igényel, amely a API kulcskezelésre, az adatbázisbiztonságra és a tárolási engedélyekre összpontosít. [S1] A nem megfelelően konfigurált sorszintű biztonság (RLS) vagy a kitett érzékeny kulcsok jelentős adatlehetőségi incidensekhez vezethetnek. [S2] [S3]
Mi változott
Ez a kutatás a Supabase környezetek alapvető biztonsági ellenőrzéseit egyesíti a hivatalos architektúra irányelvek alapján. [S1] Az alapértelmezett fejlesztési konfigurációkról a gyártási körülmények között megerősített testhelyzetekre való átállásra összpontosít, különös tekintettel a hozzáférés-vezérlési mechanizmusokra. [S2] [S3]
Kit érint
A Supabase-t háttérszolgáltatásként (BaaS) használó alkalmazások érintettek, különösen azok, amelyek felhasználóspecifikus adatokat vagy magánvagyont kezelnek. [S2] Azok a fejlesztők, akik a service_role kulcsot az ügyféloldali csomagokban tartalmazzák, vagy nem engedélyezik a RLS-t, nagy kockázatnak vannak kitéve. [S1]
Hogyan működik a probléma
A Supabase a PostgreSQL sorszintű biztonságát használja az adathozzáférés korlátozására. [S2] Alapértelmezés szerint, ha a RLS nincs engedélyezve egy táblán, a anon kulccsal – amely gyakran nyilvános – minden felhasználó hozzáférhet az összes rekordhoz. [S1] Hasonlóképpen, a Supabase Storage explicit házirendeket igényel annak meghatározásához, hogy mely felhasználók vagy szerepkörök hajthatnak végre műveleteket a fájlgyűjtőkön. [S3]
Mit kap egy támadó
A nyilvános API kulccsal rendelkező támadó kihasználhatja a RLS hiányzó táblákat más felhasználók adatainak olvasására, módosítására vagy törlésére. [S1] [S2] A tárolóhelyekhez való jogosulatlan hozzáférés a privát felhasználói fájlok nyilvánosságra kerüléséhez vagy a kritikus alkalmazáselemek törléséhez vezethet. [S3]
Hogyan teszteli a FixVibe
A FixVibe most ezt is lefedi a Supabase ellenőrzés részeként. A baas.supabase-security-checklist-backfill nyilvánosan áttekinti a Supabase Tárolótár metaadatokat, névtelen objektumlistázási expozíciót, érzékeny csoportelnevezést és a nyilvános anon határról érkező, névtelen tárolójeleket. A kapcsolódó élő ellenőrzések megvizsgálják a szolgáltatási szerepkulcsok kitettségét, a Supabase REST/RLS testhelyzetet és a lerakat SQL-migrációit a hiányzó RLS jelek miatt.
Mit kell javítani
Mindig engedélyezze a sorszintű biztonságot az adatbázistáblákon, és alkalmazzon részletes házirendeket a hitelesített felhasználók számára. [S2] Győződjön meg arról, hogy csak az „anon” kulcsot használja az ügyféloldali kódban, míg a „service_role” kulcs a szerveren marad. [S1] Konfigurálja a Tárolási hozzáférés-vezérlést annak biztosítására, hogy a fájlcsoportok alapértelmezés szerint privátak legyenek, és a hozzáférést csak meghatározott biztonsági házirendeken keresztül biztosítsák. [S3]