Chiave privilegiata nel frontend
Le chiavi service-role e secret aggirano RLS e non devono mai raggiungere il browser.
Controlli di sicurezza Supabase
Controlla il confine Supabase realmente raggiungibile
BoringSec distingue le chiavi client pubbliche dai segreti privilegiati e usa sonde limitate in sola lettura quando il progetto è verificabile.
Usalo dopo modifiche a policy, storage, autenticazione o ambiente e prima di esporre dati reali.
Scansiona solo sistemi di tua proprietà o per cui sei autorizzato. I motori approfonditi richiedono un’autorizzazione verificata e possono non essere disponibili.
rapporto / esempio di rilievoIllustrativo
Critico
Esempio di struttura del rapporto
Una richiesta anonima può leggere righe
- Evidenza
- Una lettura limitata con contesto pubblico ha restituito dati; l’evidenza acquisita è minimizzata.
- Cosa significa
- Il percorso osservato indica RLS assente o troppo permissiva.
- Correggi e verifica
- Abilita RLS, applica il minimo privilegio, esamina l’esposizione e verifica.
Questo rilievo è illustrativo, non è un risultato della tua applicazione. I rapporti reali mostrano scanner, stato dell’evidenza e limiti di copertura del bersaglio.
Percorsi di rischio comuni
Cosa merita un controllo più attento
Sono rischi rilevanti per i progetti Supabase, non affermazioni su ogni progetto. Un rilievo appare solo quando lo scanner fornisce evidenza.
Lettura anonima delle righe
Policy mancanti o troppo ampie possono esporre dati tramite l’API pubblica.
Storage pubblico o enumerabile
Policy di bucket e oggetti possono esporre file non collegati dall’interfaccia.
Copertura trasparente
Cosa può dimostrare ogni superficie di scansione
URL, codice collegato e motori approfonditi autorizzati rispondono a domande diverse. BoringSec separa le fonti e mostra stati parziali, bloccati o non disponibili.
Leggi la metodologia pubblica (in inglese)Classificazione di progetto e chiavi
Rileva URL supportati e distingue chiavi pubbliche da formati privilegiati.
Sonde limitate sulle tabelle
Usa letture con limite e segnala esiti limitati, vulnerabili, non verificati o saltati.
Stato dello storage
Controlla elenchi di bucket limitati senza caricare, cambiare o eliminare oggetti.
Incertezza esplicita
Errori, limiti e rifiuti riducono la copertura invece di produrre un’approvazione.
Dall’osservazione alla verifica
Un rapporto pensato per l’azione successiva
- 01
Osserva
Ispeziona la risposta pubblica e avvia i motori in background applicabili.
- 02
Verifica le evidenze
Controlla cosa è stato osservato, da quale scanner e con quale affidabilità.
- 03
Correggi nel contesto
Usa una correzione concreta e il contesto rilevante per RLS Supabase.
- 04
Ripeti il test
Esegui una nuova valutazione; il monitoraggio rileva regressioni successive.
Domande prima della scansione
Una chiave anon Supabase è un segreto trapelato?
No. Le chiavi pubbliche sono previste; RLS e policy di storage sono il confine.
La scansione modifica il database?
No. Le sonde sono limitate e in sola lettura; non inseriscono, aggiornano o eliminano.
Può dimostrare tutte le policy RLS?
No. Dimostra solo i percorsi osservati; i ruoli autenticati richiedono contesto autorizzato.
Un risultato pulito prova che Supabase è sicuro?
No. La copertura parziale, bloccata o non disponibile resta visibile.
Controlla l’applicazione pubblicata e verifica ogni correzione
Inizia dall’URL pubblico. Aggiungi codice o contesto autenticato solo quando vuoi ampliare la copertura.
Avvia una scansione di sicurezza