A password-reset form can disclose account membership through a sentence as small as “That email address is not registered.” A different response for existing accounts creates a way to distinguish users from non-users. This matters even when no password is exposed.
The OWASP Forgot Password Cheat Sheet recommends consistent messages for existing and non-existing accounts, along with consistent response timing and controls against excessive requests. The wording is one part of the design, not the whole protection.
Help the person without confirming membership
A response can explain that instructions will be sent if the address is associated with an account. It can also suggest checking the entered address and relevant mail folders. Avoid following a neutral headline with an account-specific hint elsewhere on the same screen.
Think through support links too. A separate “find my account” feature that immediately confirms membership can undermine the reset form’s restraint. Review the complete recovery journey, including mobile interfaces and translated messages.
Keep the server behaviour consistent
A visually identical response is insufficient if status codes, response bodies, or obvious timing differences reveal the same information. Test authorised development or staging accounts representing both cases. Record what the interface and server return, without involving unrelated real users.
Reset tokens also need appropriate randomness, limited validity, and single-use handling. Rate limits should reduce abuse without making it easy for an attacker to lock a legitimate person out merely by requesting resets. Use the security requirements of the application rather than copying a few front-end sentences.
Finally, make the reset email understandable to its recipient. Explain why it arrived and what to do if the request was not theirs. A secure flow should protect account information while leaving a legitimate user with a clear, workable route back into their own account.