Supabase leaked password protection disabled: how to fix it

To fix the “leaked password protection disabled” warning, upgrade the project to the Pro plan, open the Auth settings of the email provider, and turn on the leaked password check. The warning means that Supabase Auth accepts passwords that appear in public breach lists. The setting is off by default. The warning does not mean that someone hacked your project.

This guide explains the warning, shows how to confirm it, and gives the steps to fix it. It also shows what to do for users who already have weak passwords, and what to do if you stay on the Free plan.

What does “leaked password protection disabled” mean?

It means that Supabase Auth does not compare new passwords with a list of leaked passwords. A user can choose a password such as Summer2024! even when attackers know it.

Supabase Auth can do this check. According to the Supabase password security docs, Auth uses the open-source HaveIBeenPwned.org Pwned Passwords API to find known leaked passwords. When the check is on, Auth rejects a password that matches.

The check protects your users from a common attack. People reuse passwords. When another website leaks a password, attackers try the same email and password on many other sites. This attack is called credential stuffing. A password that is in a leak list is a password that attackers already try first.

The Security Advisor in the Supabase dashboard shows the warning. The advisor reports a missing setting. It does not scan your users, and it does not read their passwords. Supabase stores password hashes, so neither you nor the advisor can see the plain passwords.

Vibe coding tools often create this state. The tool creates a Supabase project and adds a sign-up form. The form works, so no one opens the Auth settings. The default settings stay unchanged.

How do I confirm that the problem exists in my project?

Use the dashboard first. Then test the real sign-up behavior of your app.

1. Open the Supabase dashboard and select your project.
2. Open the Security Advisor and read the list of warnings. Look for a warning about leaked password protection.
3. Open the Auth settings and find the email provider. Read the password settings.
4. Check your plan in the billing settings of the organization.

Then test the behavior with a throw-away account. Use a very common password, such as password123. Send the request to your own project:

curl -s -X POST "https://YOUR-PROJECT-REF.supabase.co/auth/v1/signup" \
  -H "apikey: YOUR_PUBLISHABLE_OR_ANON_KEY" \
  -H "Content-Type: application/json" \
  -d '{"email":"test+leak@example.com","password":"password123"}'

Use an email address that you own. Replace the placeholders with your project values. The publishable or anon key is public by design, so it is safe to use here.

Read the result. If the response creates a user, the project accepted a very common password. This result is expected when the check is off and when the length rules are low. If the response is an error about a weak password, a rule blocks the password.

Note: A rejected password does not prove that the leak check is on. A minimum length of 12 or a character rule can also reject the password. Read the settings page to see which rule is active.

Delete the test user after the test. Open Authentication, then Users, and remove the account.

How do I turn on leaked password protection?

Turn it on in the Auth settings. The check needs the Pro plan. The password security docs state: “Leaked password protection is available on the Pro Plan and above.”

1. Upgrade the plan. Open the billing settings of the organization. Select the Pro plan. Skip this step when the project is already on Pro or higher.
2. Open the Auth settings. Select Authentication in the dashboard. Open the settings of the email provider. The location of the menu items can change, so read the page title and the labels in your own dashboard.
3. Turn on the leaked password check. Find the option that prevents the use of leaked passwords. Switch it on and save.
4. Set the minimum length. The docs say that anything less than 8 characters is not recommended. Use 10 or more for a new project.
5. Set the required characters. The docs list four types: digits, lowercase letters, uppercase letters, and symbols. Choose the stricter options when your users accept them.
6. Run the curl test again. Send the password123 request again. The response must now be an error.
7. Reload the Security Advisor. The warning must disappear after you refresh the list.

Caution: Do not set a very strict composition rule without a test. A rule that rejects most passwords makes people leave the sign-up form. Length gives more protection than symbol rules. A long password is also easier for the user to remember.

What happens in my frontend after the change?

The sign-up call returns an error when a password is rejected. Your form must show a clear message. A form that shows “Something went wrong” makes users try the same password again.

Show the reason in plain text. For example: “This password appears in a known leak. Choose a different password.” The weak password error guide shows how to read the error in the client code.

Test the sign-up form, the password reset form, and the “change password” page. Each of them sets a password. If one form has no error handling, a rejected password looks like a frozen page.

What do I do about users who already have weak passwords?

The new setting does not change old passwords. The docs say that existing users can still sign in with their current password, even when it does not meet the new rules. For this reason, turning on the check closes the door for new passwords only.

You cannot find the weak passwords yourself. Supabase stores hashes. You cannot compare them with a leak list. Use one of these options instead.

To start a reset for one user, use the reset email call of the client library:

const { error } = await supabase.auth.resetPasswordForEmail(email, {
  redirectTo: "https://your-app.example/update-password",
});

Add the redirect URL to the allowed list in the Auth settings first. A reset flow with a wrong redirect URL fails, and it can also open a redirect risk. Read the Lovable forgot password guide if your reset page does not work.

Send the reset request in small groups. A large batch of emails can reach the email rate limit of your sender. The Supabase docs say that the default email service has a very low limit and recommend a custom SMTP server for production. Set up your own SMTP before a mass reset.

Tell your users why you ask for a new password. Write one short, true sentence. Do not say that a breach happened if no breach happened.

How do I check whether attackers already used leaked passwords?

Check the Auth logs and the user list. You look for patterns that credential stuffing creates.

1. Open the Auth logs. In the dashboard, open Logs and select the Auth logs. Set the time range to the last 7 days.
2. Look for many failed sign-ins. A normal user fails a few times. A bot fails hundreds of times with different emails.
3. Look for one IP address with many emails. One source that tries many accounts is a strong sign of credential stuffing.
4. Look for successful sign-ins after a long run of failures. This pattern means that a guess worked.
5. Sort the users by creation time. Look for many new accounts in a short time with similar email names.
6. Check the accounts with high privilege. Open the table that holds roles or plans. Check the last sign-in time of each admin.

If you find a successful sign-in that you cannot explain, act at once:

1. Sign the user out of all sessions. Use the Auth admin API or the dashboard user menu.
2. Force a password reset for the account.
3. Check what the account changed in your tables during that period.
4. Contact the real owner by email.

Auth logs are not a full record of what a user did inside your app. They show the sign-in events only. Your own application logs and database change dates show the rest.

What if I cannot use the Pro plan?

Use other controls. None of them replaces the leak check. Together they lower the risk.

1. Raise the minimum length. Set 12 characters. A longer password is harder to guess, and fewer long passwords appear in leak lists.
2. Require several character types. Use the composition options in the Auth settings.
3. Add MFA for accounts that matter. Admin accounts and paid accounts need a second factor. A leaked password alone then does not open the account.
4. Limit sign-in attempts. Put a rate limit in front of the sign-in endpoint. See API abuse protection for patterns.
5. Check the password on your own server. Your own code can call a breach-check service before it accepts a password. This work is extra code, and you must keep the check up to date. Use it only if the plan limit blocks you.
6. Offer passwordless sign-in. Magic link and one-time code flows do not store a password for the user. They have their own risks. Read the auth flows pattern page before you choose them.

A rule that is easy to forget: the leak check protects the user, not your database. Row Level Security (RLS) protects your data. A strong password does not fix a table that has no RLS policy. Read the Supabase RLS guide for the data side.

How do I stop the warning from returning?

Put the setting in your launch checklist. Review the Auth settings after each big change to the project.

1. Add the Auth settings to the checklist. Check the leak check, the minimum length, and the email confirmation setting before launch.
2. Open the Security Advisor weekly. New warnings appear when you add tables, functions, or settings.
3. Record the settings in a note. When you create a second project, such as a staging project, copy the same Auth settings. A new project starts with the default values again.
4. Test sign-up in each environment. Run the curl test from the confirm section against staging and production.
5. Keep a test in your pipeline. A short script can send a weak password to sign-up and fail the build when the response creates a user. Use a test email address and delete the user after the run.
6. Scan the deployed app. A scan checks the live behavior, not the settings page.

Check the same settings after you move a project to a new organization or restore a backup. Settings can differ between the old and the new project.

When should I get help?

Get help in these cases:

• The Auth logs show successful sign-ins that you cannot explain, and the accounts hold personal data. Ask a security engineer to review the project. You may have legal duties to report an incident.
• Many users report that someone changed their account. Reset all sessions and passwords, then review the logs for the full period.
• You cannot find the setting in the dashboard. Open a ticket with Supabase support and give the project reference.
• The advisor warning stays after you turn the check on and refresh. Contact Supabase support with a screenshot.

After you finish, run the curl test one more time with a weak password. The response must be an error, and the Security Advisor must show no leaked password warning.