Cârligul
Securizarea unui proiect Supabase necesită o abordare pe mai multe straturi care să se concentreze pe managementul cheilor API, securitatea bazei de date și permisiunile de stocare. [S1] Securitatea la nivel de rând configurată incorect (RLS) sau cheile sensibile expuse pot duce la incidente semnificative de expunere a datelor. [S2] [S3]
Ce s-a schimbat
Această cercetare consolidează controalele de securitate de bază pentru mediile Supabase pe baza ghidurilor oficiale de arhitectură. [S1] Se concentrează pe tranziția de la configurațiile implicite de dezvoltare la posturile întărite de producție, în special în ceea ce privește mecanismele de control al accesului. [S2] [S3]
Cine este afectat
Aplicațiile care utilizează Supabase ca Backend-as-a-Service (BaaS) sunt afectate, în special cele care gestionează date specifice utilizatorului sau active private. [S2] Dezvoltatorii care includ cheia service_role în pachetele client sau nu reușesc să activeze RLS sunt expuși unui risc ridicat. [S1]
Cum funcționează problema
Supabase folosește Row Level Security de la PostgreSQL pentru a restricționa accesul la date. [S2] În mod implicit, dacă RLS nu este activat pe un tabel, orice utilizator cu cheia anon – care este adesea publică – poate accesa toate înregistrările. [S1] În mod similar, Supabase Stocarea necesită politici explicite pentru a defini ce utilizatori sau roluri pot efectua operațiuni pe compartimente de fișiere. [S3]
Ce primește un atacator
Un atacator care deține o cheie publică API poate exploata tabelele care lipsesc RLS pentru a citi, modifica sau șterge date care aparțin altor utilizatori. [S1] [S2] Accesul neautorizat la compartimentele de stocare poate duce la expunerea fișierelor private de utilizator sau la ștergerea elementelor critice ale aplicației. [S3]
Cum testează FixVibe pentru aceasta
FixVibe acoperă acum acest lucru ca parte a verificărilor sale Supabase. baas.supabase-security-checklist-backfill examinează metadatele publice Supabase ale compartimentului de stocare, expunerea anonimă la listarea obiectelor, denumirea sensibilă a compartimentului și semnalele de stocare anon-legate de la granița publică. Verificările în direct asociate inspectează expunerea cheii rolului de serviciu, poziția Supabase REST/RLS și migrațiile SQL din depozit pentru lipsa RLS.
Ce trebuie remediat
Activați întotdeauna securitatea la nivel de rând pe tabelele bazei de date și implementați politici granulare pentru utilizatorii autentificați. [S2] Asigurați-vă că numai cheia „anon” este utilizată în codul clientului, în timp ce cheia „service_role” rămâne pe server. [S1] Configurați controlul accesului la stocare pentru a vă asigura că compartimentele de fișiere sunt private în mod implicit și că accesul este acordat numai prin politici de securitate definite. [S3]