In breve
La leaked password protection fa rifiutare a Supabase Auth le password presenti nell’archivio delle violazioni di Have I Been Pwned. È disponibile dal piano Pro in su. Il 23 ottobre 2026 quell’archivio conteneva password123 2.266.543 volte, e il mio Supabase Auth locale, con le impostazioni predefinite, l’ha accettata alla registrazione. Non giudica la robustezza: Lovable2026! compariva 0 volte. La attivi dove può e imposti comunque una lunghezza minima maggiore.
Il mio checker di sicurezza per Supabase gratuito legge le impostazioni di autenticazione di un progetto, e “Protezione dalle password compromesse disattivata” è una delle sue regole, accanto a “Lunghezza minima della password troppo corta”. Questa nota spiega cosa controlla davvero l’impostazione, con numeri presi dallo stesso servizio che usa.
Cos’è la leaked password protection in Supabase?
È una delle impostazioni sulle password nelle impostazioni di autenticazione del suo progetto nella Dashboard. Quando è attiva, Supabase Auth controlla ogni nuova password sul servizio Pwned Passwords di Have I Been Pwned e rifiuta quelle che vi si trovano. La guida alla sicurezza delle password di Supabase la elenca insieme a lunghezza minima e caratteri richiesti e precisa che è disponibile dal piano Pro in su.
Il controllo non invia mai la password. Pwned Passwords usa una query per intervalli in k-anonymity: il client calcola l’hash SHA-1 della password, invia solo i primi 5 caratteri dell’hash e confronta in locale i suffissi restituiti.
Quanto spesso le password comuni compaiono nelle violazioni?
Ho eseguito io stesso quella query per intervalli il 23 ottobre 2026, per alcune password che vedo negli account di test e nei dati di esempio generati dall’IA:
| Password | Volte viste nelle violazioni |
|---|---|
123456 |
210.461.208 |
qwerty123 |
13.871.714 |
password123 |
2.266.543 |
Password1! |
584.516 |
Welcome1! |
239.099 |
Summer2026! |
45 |
supabase123 |
7 |
Lovable2026! |
0 |
123456 è escluso dal grafico perché appiattirebbe tutte le altre barre. Le ultime tre righe sono il punto: una password può essere assente da ogni violazione ed essere comunque facile da indovinare. La leaked password protection ferma il credential stuffing con password note. Non misura la robustezza.
Cosa succede senza?
Su uno stack Supabase locale (CLI 2.109.1, Auth v2.192.0) con le impostazioni predefinite, ho registrato un utente di test con password123. Auth ha risposto 200 e ha creato l’utente. L’unica cosa rifiutata è stata una password di 5 caratteri, con 422 weak_password e il motivo length, perché il minimo predefinito in locale è di 6 caratteri.
Quindi, senza l’impostazione, nulla si frappone tra un utente e una password trapelata milioni di volte, a parte la regola sulla lunghezza.
Cosa conviene impostare?
- Su Pro e superiori: attivi la leaked password protection. Gli utenti esistenti continuano ad accedere, e secondo la guida quelli la cui password non rispetta i nuovi requisiti ricevono una
WeakPasswordErrorche ne spiega il motivo, così può chiedere loro di cambiarla. - Su ogni piano: aumenti la lunghezza minima. La guida considera sconsigliato tutto ciò che è sotto gli 8 caratteri; la regola del mio checker suggerisce 12 o più.
- Richieda classi di caratteri solo se i suoi utenti possono sopportarlo; la lunghezza vale più di un simbolo obbligatorio.
- Aggiunga la MFA per gli account che contano e richieda la password attuale o un nonce di riautenticazione per cambiare una password; entrambi sono nella stessa guida.
La leaked password protection è una delle impostazioni di autenticazione che esistono solo nella configurazione del progetto ospitato, non nel suo repository. Il resto di ciò che controllo su un’app Supabase, dalla RLS ai rate limit sul login, è nella mia checklist di sicurezza per le app Lovable, e cosa copre Supabase rispetto a cosa spetta a lei è in Supabase è sicuro.