How to Enable Supabase Leaked Password Protection and Why It Matters

Decloak is an AI-powered web security intelligence platform that scans a site's HTTP/TLS posture, JavaScript, and third-party scripts to produce a report anyone can read. This guide is part of Decloak's library of practical, source-backed security guidance.

Key takeaways

• Supabase can reject passwords that appear in public breach databases via the HaveIBeenPwned k - anonymity API.
• The feature is only on Pro plans and higher, and is off by default for new projects.
• Enable it in the dashboard under Auth → Providers → Email with the "Prevent the use of leaked passwords" toggle.
• The check adds only a few milliseconds of latency and never sends the full password hash outside Supabase.
• Pair this protection with a minimum password length (≥12 characters), rate limiting, and MFA for defense - in - depth.

What is Supabase leaked password protection?

Supabase leaked password protection is a credential - stuffing mitigation that rejects passwords previously exposed in data - breach dumps. It queries the open - source HaveIBeenPwned "Pwned Passwords" API using a k - anonymity lookup, so the full password hash never leaves Supabase’s servers.

How does the k - anonymity check work?

When a user signs up, Supabase hashes the password locally with SHA - 1, extracts the first five hexadecimal characters, and sends that prefix to the HaveIBeenPwned endpoint. The service returns a list of hash suffixes that share the same prefix; Supabase then compares the remaining suffix locally. If a match is found, the password is rejected. This method protects user privacy while still leveraging a massive breach database.

Which plans include the feature?

The toggle is only available on the Pro plan and above. Free tier projects cannot enable the protection; attempting to do so will result in a disabled UI control.

Default state and how to enable it

For new Supabase projects the protection is off by default. To turn it on:

1. Open the Supabase dashboard.
2. Navigate to Auth → Providers → Email.
3. Locate the toggle labeled Prevent the use of leaked passwords.
4. Switch the toggle to On and save the changes.

Performance impact

The k - anonymity request is tiny - typically adding only a few milliseconds to the sign - up flow. Because only a 5 - character prefix is transmitted, network overhead is negligible.

Recommended complementary hardening steps

• Minimum password length: Set the required length to at least 12 characters in the same Auth settings panel.
• Rate limiting: Enable the built - in sign - up and sign - in rate limits to slow down credential - stuffing attacks.
• Multi - factor authentication (MFA): Require MFA for sensitive operations or for all users where feasible.
• Regularly review auth logs: Look for repeated rejected password attempts that may indicate an ongoing attack.

How to verify the protection works

After enabling the toggle, test with a known breached password such as "password123" (which appears in the HaveIBeenPwned database). The sign - up should be blocked with an error indicating the password has been compromised. Conversely, a strong, unique password should succeed.

Common pitfalls

• Assuming it protects all passwords: Only passwords that match a known breach entry are blocked. Strong, unique passwords are still allowed.
• Relying on it as the sole defense: It is a helpful layer but does not replace MFA, rate limiting, or secure password policies.
• Enabling on a free tier: The UI will be disabled; upgrade to Pro before attempting to toggle.

When to consider upgrading Supabase

If your application handles sensitive user data, compliance requirements, or high - value accounts, the added security of leaked password protection combined with Pro - tier features (such as advanced auth rules and higher request limits) often justifies the cost.

Related resources

• Supabase Auth documentation on password policies and MFA.
• HaveIBeenPwned API documentation for developers.
• Decloak’s free web security scan can surface exposed authentication endpoints and misconfigurations, helping you verify that your auth hardening is visible from the outside.

This article follows the latest Supabase guidance as of 2026 and reflects the current feature set.