"Forgot password" looks like a tiny feature:
email -> link -> new password.
But for a few minutes, it becomes another way into an account. That makes account recovery part of the authentication system, not a convenience screen that can be added at the end of a project.
OWASP calls forgot-password functionality a common source of vulnerabilities, including user enumeration. NIST SP 800-63B-4, published on August 1, 2025, also treats account recovery as part of authenticator management. The practical takeaway is simple: if the reset flow is weaker than normal login, the strength of the login system matters less.
Use these seven mistakes as a defensive review checklist.
1. Revealing Whether an Account Exists
The classic mistake is a reset form that says:
No user exists with this email.
That message helps a real user, but it also confirms whether an address is registered. OWASP recommends returning a consistent message for existing and non-existing accounts. A safer public response is:
If an account exists for this email, reset instructions will be sent.
The response timing matters too. If valid accounts take much longer because email is sent before returning, timing can reveal the same information.
The system can still process the request. The public interface just does not confirm whether the identifier belongs to a real account.
2. Weak or Reusable Reset Tokens
A password reset link is a temporary credential. Treat it like one.
OWASP recommends that reset tokens or codes be generated with a cryptographically secure random generator, be long enough to resist guessing, be linked to the right user, be stored securely, be single-use, and expire after an appropriate period. There is no universal lifetime that fits every product. A consumer forum, banking portal, internal enterprise system, and healthcare app may need different recovery policies.
Design the token lifecycle deliberately:
Do not leave old reset links valid after a successful reset. Do not let the same link work twice. Avoid storing raw reset tokens when a stored verifier would reduce database-leak impact. Apply the same password policy used elsewhere.
3. Trusting the Wrong Host When Building Reset URLs
Reset emails often include a link back to the application. That link should use a trusted application domain.
OWASP warns not to rely blindly on the HTTP Host header when creating reset URLs. Request headers are input. A reset link should be built from a configured domain or a validated allowlist of trusted domains, not from whatever host value arrived.
Keep this boring and explicit:
- configure the public application URL per environment
- validate tenant or brand domains against an allowlist
- use HTTPS
- avoid building account-recovery links from untrusted request headers
This is not a place for clever auto-detection. Recovery emails must point users to the real service.
4. No Protection Against Reset Request Flooding
Forgot-password forms can be abused as inbox-flood buttons. Someone repeatedly submits another person's email address, and the legitimate user receives reset messages again and again.
OWASP recommends protections against excessive automated submissions, including rate limiting on a per-account basis, CAPTCHA where appropriate, or other controls. The exact control depends on the product. A public SaaS sign-in page, a mobile banking app, and an internal admin portal have different risk and usability tradeoffs.
The goal is not to lock out legitimate users. OWASP warns against locking accounts merely because forgot-password requests were submitted. Slow abuse, detect suspicious patterns, and keep recovery available.
5. Leaking the Token Through the Reset Page
A reset token should not quietly leak after the user opens the reset page.
OWASP guidance for URL tokens includes using HTTPS, adding a Referrer-Policy such as noreferrer to reduce referrer leakage, and preventing brute-force attempts against token URLs. The OWASP Web Security Testing Guide also recommends avoiding third-party resources on reset pages because URLs can leak through browser requests, analytics, scripts, images, or referral headers.
Keep reset pages minimal. They usually do not need marketing pixels, chat widgets, third-party embeds, or unnecessary external scripts. If a page contains a temporary credential in the URL, reduce where that URL can travel.
Defensive habits include:
- serve reset flows only over HTTPS
- avoid third-party resources on token-bearing reset pages
- use an appropriate
Referrer-Policy - exchange the URL token for a limited reset session when practical
- invalidate the token immediately after successful use
6. Treating Security Questions as Strong Recovery
Security questions are often private, but private is not the same as secret. A pet name, school, city, or family detail may be guessable, searchable, shared, reused, or discoverable through social media and data breaches.
OWASP says security questions should not be the sole mechanism for resetting passwords. NIST guidance is stricter in the digital authentication context: knowledge-based authentication, such as answering questions supposedly known only to the claimant, is not recognized as an acceptable authenticator for digital authentication.
That does not mean every legacy system is instantly illegal everywhere. It means product teams should not treat security questions as a strong standalone recovery factor. Prefer methods that are bound, issued, verified, monitored, and revocable, such as recovery codes, verified recovery channels, or support procedures appropriate to the account risk.
7. Forgetting What Happens After the Password Changes
The reset flow does not end when the new password is stored.
OWASP recommends notifying the user that the password has been reset and never sending the new password by email. It also recommends returning the user through the normal login mechanism rather than automatically logging them in, because automatic login adds session-handling complexity.
Existing sessions need a deliberate policy. Some products ask whether to invalidate sessions, some do it automatically, and some use risk-based rules. The right choice depends on sensitivity, but it should not be accidental.
Also remember password storage. The new password should be stored using secure password-storage practices, not reversible encryption or plain text. If your system can email a user's current password, the storage design is already broken.
A Safer Reset Flow
A safer reset flow is calm, boring, and deliberate:
- User enters an identifier.
- Application returns a neutral public response.
- Secure reset token is sent through a registered side channel.
- User presents a valid token over HTTPS.
- User sets and confirms a new password.
- Token is invalidated.
- Security notification is sent.
- Existing-session policy is applied.
- User returns through the normal authentication flow.
This checklist does not replace threat modeling or security review, but it catches common mistakes before production:
- [ ] Same public response for existing and non-existing accounts?
- [ ] Similar response timing?
- [ ] Reset tokens securely generated?
- [ ] Tokens single-use?
- [ ] Tokens expire?
- [ ] Reset requests rate-limited?
- [ ] Trusted domain used for reset URLs?
- [ ] HTTPS used throughout the flow?
- [ ] Token leakage minimized?
- [ ] Security questions avoided as sole recovery?
- [ ] User notified after reset?
- [ ] Existing sessions handled deliberately?
Final Thoughts
A password reset flow is a temporary alternative authentication path. If it confirms valid accounts, issues weak tokens, trusts the wrong host, floods inboxes, leaks URLs, depends on security questions, or forgets session handling, it quietly weakens the app even when login looks strong.
Secure recovery is not about making users suffer. It is about helping the right person recover access without giving the reset feature more power than it deserves.
For more practical software and security articles, visit the Vast Edge blog. If your team is planning a web or mobile app and wants authentication flows designed carefully from the start, explore our software development services or contact Vast Edge Services.