Different error messages for login tell attackers which emails exist
Your login page returns one message when the email is unknown and a different message when the password is wrong. That sounds helpful. It also tells strangers which addresses are registered before they try to guess passwords.
What can go wrong
A typical AI-generated auth handler returns distinct strings:
- Unknown email → a message that the user does not exist or the email is not registered
- Wrong password → a message that the password is wrong or incorrect
An attacker can script login attempts with a list of emails. Different responses become a harvest list of valid accounts. The next step is password spraying or targeted phishing against addresses you confirmed exist.
The fix is not hiding the UI message only. The API response must use the same generic error for both failure paths, for example a single invalid-credentials message.
It happened for real
Practitioner writeups in 2026 call this a recurring vibe-coding auth mistake: distinct failure strings in the same handler (DEV bezael Problem 2 cluster). Password-reset flows that leak whether an email is registered vs whether a token is wrong create the same harvesting shape.
How to check yours
Seatbelt flags this automatically (partial). Repo scans soft-flag login when the same auth handler contains both user-not-found and wrong-password literals. URL Ship Read catches the pattern in served login bundles too.
Honest holes: middleware-only auth, framework defaults we cannot see statically, or errors built from runtime variables may slip through. A soft flag means read the handler yourself.
Ask your agent: "Show every login and forgot-password error path. Do unknown-user and wrong-password return the same JSON message and status code?"
Manual check: try a random email and a known email with a wrong password. If the messages differ, you are leaking registration state.
Fix direction
Return one generic message for both paths: the same invalid-credentials wording (or identical JSON shape). Log the real reason server-side only.
Paste into your agent: "Unify login failure responses. Same status code and message for both failure paths. Never reveal whether the email exists."