Supabase leaked password protection : ce qu’elle bloque

Mon audit de sécurité Supabase gratuit lit les réglages d’authentification d’un projet, et « Protection contre les mots de passe compromis désactivée » est l’une de ses règles, à côté de « Longueur minimale de mot de passe trop courte ». Cette note explique ce que le réglage vérifie réellement, avec des chiffres tirés du même service que celui qu’il utilise.

Qu’est-ce que la leaked password protection dans Supabase ?

C’est l’un des réglages de mot de passe dans les réglages d’authentification de votre projet, dans le Dashboard. Quand elle est activée, Supabase Auth compare chaque nouveau mot de passe au service Pwned Passwords de Have I Been Pwned et rejette ceux qui y figurent. Le guide de sécurité des mots de passe de Supabase la range avec la longueur minimale et les caractères requis, et précise qu’elle est disponible à partir de l’offre Pro.

La vérification n’envoie jamais le mot de passe. Pwned Passwords utilise une requête par plage en k-anonymat : le client hache le mot de passe en SHA-1, n’envoie que les 5 premiers caractères du hachage et compare localement les suffixes renvoyés.

À quelle fréquence les mots de passe courants apparaissent-ils dans les fuites ?

J’ai exécuté moi-même cette requête par plage le 23 octobre 2026, pour quelques mots de passe que je vois dans des comptes de test et des données de départ générées par l’IA :

Mot de passe	Fois vu dans des fuites
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 est absent du graphique parce qu’il écraserait toutes les autres barres. Les trois dernières lignes sont l’enjeu : un mot de passe peut être absent de toutes les fuites et rester facile à deviner. La leaked password protection arrête le credential stuffing avec des mots de passe connus. Elle ne mesure pas la robustesse.

Que se passe-t-il sans elle ?

Sur un stack Supabase local (CLI 2.109.1, Auth v2.192.0) avec les réglages par défaut, j’ai inscrit un utilisateur de test avec password123. Auth a répondu 200 et a créé l’utilisateur. La seule chose refusée était un mot de passe de 5 caractères, avec 422 weak_password et la raison length, parce que le minimum par défaut en local est de 6 caractères.

Sans le réglage, rien ne sépare donc un utilisateur d’un mot de passe qui a fuité des millions de fois, à part la règle de longueur.

Que faut-il régler ?

1. Sur Pro et au-dessus : activez la leaked password protection. Les utilisateurs existants continuent de se connecter, et selon le guide, ceux dont le mot de passe ne respecte pas les nouvelles exigences reçoivent une WeakPasswordError qui explique pourquoi, ce qui permet de leur demander d’en changer.
2. Sur toutes les offres : augmentez la longueur minimale. Le guide juge déconseillé tout ce qui fait moins de 8 caractères ; la règle de mon audit suggère 12 ou plus.
3. Exigez des classes de caractères seulement si vos utilisateurs peuvent le supporter ; la longueur apporte plus qu’un symbole obligatoire.
4. Ajoutez la MFA pour les comptes qui comptent, et exigez le mot de passe actuel ou un nonce de réauthentification pour changer un mot de passe ; les deux sont dans le même guide.

La leaked password protection est l’un des réglages d’authentification qui n’existent que dans la configuration du projet hébergé, pas dans votre dépôt. Le reste de ce que je vérifie sur une application Supabase, de la RLS aux limites de débit sur la connexion, est dans ma checklist de sécurité d’une application Lovable, et ce que Supabase couvre par rapport à ce qui vous revient est dans Supabase est-il sûr.