Fix the Supabase weak password error

If Supabase says “Password is known to be weak and easy to guess, please choose a different one,” try a new, unique password generated by a password manager. If you maintain the app, inspect the Auth error and the project’s password policy before changing any settings.

This guide covers a rejected account password in Supabase-backed apps, including Lovable. To configure the protection itself, use the Lovable leaked-password protection guide.

Identify which rule rejected the password

Supabase lets a project configure minimum length, required character types, and breached-password checks. Its leaked-password protection uses Have I Been Pwned and is currently available on Pro plans and above. A password can satisfy length and character rules and still fail a breached-password check. See Supabase’s password security documentation.

The broader weak_password error means the submitted password does not satisfy the project’s requirements. Use the error code and available details rather than assuming every password failure has the same cause. Supabase documents codes in its Auth error reference.

Fix it as an app user

Generate a fresh password, save it in your password manager, and retry the form. Avoid repeatedly adding a digit to the rejected password. If the app displays character or length requirements, make sure the generated value meets them.

If a fresh password still fails, send support the error text, the action you were attempting, and the approximate time. Keep the password, recovery link, and session tokens out of that message.

Fix the form as a developer

Reproduce the problem with a test account in a non-production project. Record the returned error code and the operation: signup, password update, or sign-in. Do not record the submitted password or the full request body.

Then check these points:

1. Project selection. Read the configured project URL. A preview build may use a different project’s password rules.
2. Visible instructions. Match the form’s password requirements to the server policy. Client validation should help the user before submission, but the server remains authoritative.
3. Error presentation. Map a password-policy failure to a message beside the password field. Treat rate limits, recovery-session errors, and network failures separately.
4. Success handling. Only show account creation or password-change success after checking the response.

For a confirmed breached-password rejection, an appropriate message is: “Choose a different, unique password. This password appears in known breach data.” For a generic policy failure, explain the applicable rules instead of claiming a breach match.

Verify the fix

Use a disposable account to check both signup and password change. Test a value that fails your configured length rule and a generated value that satisfies it. Confirm that the first produces useful feedback and the second completes the intended operation. Check the logs for accidental password capture.

Do not disable leaked-password protection merely to make a test password work. Replace the test credential. This error alone also does not prove that the app’s database has been breached.

Related checks

• Configure leaked-password protection in a Lovable app
• Review authentication implementation
• Check Supabase row-level security

Documentation reviewed October 8, 2026.