Il gancio
La protezione di un progetto Supabase richiede un approccio a più livelli incentrato sulla gestione delle chiavi API, sulla sicurezza del database e sulle autorizzazioni di archiviazione. [S1] La sicurezza a livello di riga configurata in modo errato (RLS) o le chiavi sensibili esposte possono portare a significativi incidenti di esposizione dei dati. [S2] [S3]
Cosa è cambiato
Questa ricerca consolida i controlli di sicurezza principali per gli ambienti Supabase sulla base delle linee guida ufficiali dell'architettura. [S1] Si concentra sulla transizione dalle configurazioni di sviluppo predefinite a posture rafforzate dalla produzione, in particolare per quanto riguarda i meccanismi di controllo degli accessi. [S2] [S3]
Chi è interessato
Sono interessate le applicazioni che utilizzano Supabase come backend-as-a-Service (BaaS), in particolare quelle che gestiscono dati specifici dell'utente o risorse private. [S2] Gli sviluppatori che includono la chiave service_role nei bundle lato client o che non riescono ad abilitare RLS sono ad alto rischio. [S1]
Come funziona il problema
Supabase sfrutta la sicurezza a livello di riga di PostgreSQL per limitare l'accesso ai dati. [S2] Per impostazione predefinita, se RLS non è abilitato su una tabella, qualsiasi utente con la chiave anon, che spesso è pubblica, può accedere a tutti i record. [S1] Allo stesso modo, Supabase Storage richiede policy esplicite per definire quali utenti o ruoli possono eseguire operazioni sui bucket di file. [S3]
Cosa ottiene un utente malintenzionato
Un utente malintenzionato in possesso di una chiave pubblica API può sfruttare le tabelle in cui manca RLS per leggere, modificare o eliminare dati appartenenti ad altri utenti. [S1] [S2] L'accesso non autorizzato ai bucket di archiviazione può portare all'esposizione di file utente privati o all'eliminazione di risorse applicative critiche. [S3]
Come lo esegue il test FixVibe
FixVibe ora copre questo aspetto come parte dei suoi controlli Supabase. baas.supabase-security-checklist-backfill esamina i metadati del bucket di archiviazione pubblico Supabase, l'esposizione di elenchi di oggetti anonimi, la denominazione sensibile dei bucket e i segnali di archiviazione anon-bound dal confine anon pubblico. I controlli in tempo reale correlati esaminano l'esposizione della chiave del ruolo di servizio, la postura Supabase REST/RLS e le migrazioni SQL del repository per RLS mancante.
Cosa correggere
Abilita sempre la sicurezza a livello di riga sulle tabelle del database e implementa policy granulari per gli utenti autenticati. [S2] Assicurati che solo la chiave "anon" venga utilizzata nel codice lato client, mentre la chiave "service_role" rimane sul server. [S1] Configura il controllo dell'accesso allo storage per garantire che i bucket di file siano privati per impostazione predefinita e che l'accesso venga concesso solo tramite policy di sicurezza definite. [S3]