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
Prima della verifica della proprietà del dominio, BoringSec distingue le chiavi pubbliche dai segreti privilegiati ed esegue sonde limitate in sola lettura. La verifica sblocca solo Injection, XSS, Ports e i motori esterni Nuclei, OWASP ZAP e Medusa.
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
Nel report iniziale rileva URL supportati e distingue chiavi pubbliche da formati privilegiati.
Sonde limitate sulle tabelle
Prima della verifica della proprietà usa letture limitate e segnala protetto, esposizione verificata o non conclusivo.
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