Fix: Supabase Leaked Password Protection Disabled

"Leaked Password Protection Disabled" is a Supabase Security Advisor warning: your project currently lets users sign up or reset to passwords that appear in known data breaches. Fix it in Dashboard → Authentication → Passwords by turning on "Prevent use of leaked passwords." It checks new passwords against HaveIBeenPwned without ever sending the password.

If the Supabase Security Advisor (or a report from Lovable, Bolt, or another AI builder) flagged "Leaked Password Protection Disabled," it's a real, worth-fixing warning — but a five-minute one. It doesn't mean anything has leaked. It means your project isn't yet rejecting passwords that are already circulating in breach dumps, so a user can pick password123 and Supabase will happily accept it.

What does "Leaked Password Protection Disabled" mean?

It means Supabase Auth is not checking new passwords against a database of previously breached passwords. When the protection is enabled, every signup and password change is compared against HaveIBeenPwned's Pwned Passwords list — over 600 million passwords exposed in real breaches — and Supabase rejects any password on that list. When it's disabled (the default), that check simply doesn't run, and users can register with credentials attackers already have in their wordlists.

This matters because credential stuffing is one of the most common ways accounts get taken over: attackers replay username/password pairs from old breaches against new sites, betting on password reuse. Rejecting known-breached passwords at signup shuts that door before it opens.

Have I Been Pwned's Pwned Passwords service tracks over 600 million real-world compromised passwords gathered from data breaches. Supabase's leaked-password check queries this exact dataset, so a "no" from it means the password has literally shown up in a breach before.

How to enable leaked password protection

It's a single toggle:

1. Open your project in the Supabase Dashboard.
2. Go to Authentication, then your email/password settings — the Supabase docs link straight to the page. (Supabase has shuffled this between the Email provider settings and a dedicated password/attack-protection section across dashboard versions, so look for the password options under Authentication.)
3. Turn on "Prevent use of leaked passwords."
4. Save.

That's it — new signups and password changes are now checked. The Security Advisor warning clears on its next run.

While you're on that screen, set a minimum password length (8 is the floor; 10–12 is better) and consider requiring a mix of character types. Length and breach-checking together are far stronger than complexity rules alone.

Does Supabase send my users' passwords to HaveIBeenPwned?

No — and this is the part worth understanding before you enable it. The only public interface HaveIBeenPwned offers for this is its k-anonymity range API, which is how the check works: the password is hashed with SHA-1, only the first five characters of that hash are sent, and HaveIBeenPwned returns every breached hash sharing that prefix; the full match is then checked locally. The complete password — and even its full hash — never leaves that boundary. So enabling the feature doesn't hand your users' passwords to a third party, which is the reasonable first concern.

One caveat: it's a paid-plan feature

Leaked password protection requires the Pro plan or above. On the Free plan the Security Advisor will keep showing the warning and the toggle is unavailable. If you're pre-launch on Free, that's an acceptable known-gap — just don't ignore it once you have real users and revenue. If you can't enable it yet, you can enforce a sensible minimum length and reject obvious weak passwords in your own signup validation as a stopgap, then turn on the real check when you upgrade.

What this does — and doesn't — cover

Enabling this closes one specific hole: users choosing already-breached passwords. It is not a substitute for the rest of your auth hardening. It won't add MFA, it won't rate-limit login attempts, and it won't protect an account whose password leaks after signup. Treat it as one line item on a broader Next.js + Supabase security checklist — alongside RLS on every table, keeping the service_role key server-side, and MFA for sensitive accounts. It's a genuinely good default that most projects should have on; it's also the easiest item on that list to check off.

If you're working through the Security Advisor's other flags too, most of them come down to the same handful of misconfigurations covered in what's actually safe and what's on you in Supabase, and the checklist for vibe-coded SaaS apps if an AI builder generated your project.

FAQ

What does "Leaked Password Protection Disabled" mean in Supabase? It means your project isn't checking new passwords against known data breaches, so users can register with passwords attackers already have. Enable "Prevent use of leaked passwords" under Authentication → Passwords to fix it.

How do I enable leaked password protection in Supabase? In the Supabase Dashboard, go to Authentication → Passwords and turn on "Prevent use of leaked passwords," then save. New signups and password changes are then checked against HaveIBeenPwned.

Does enabling this send passwords to a third party? No. Supabase uses HaveIBeenPwned's k-anonymity API — it sends only the first five characters of the password's SHA-1 hash, never the password or its full hash. The password never leaves your project.

Why is the toggle greyed out? Leaked password protection requires the Pro plan or above. On the Free plan the feature is unavailable; enforce a minimum password length as a stopgap until you upgrade.

Does it check my existing users' passwords? No. It only checks passwords at signup and on password change. Existing users keep their current password until they change it, so consider prompting a reset for high-value accounts.