Every application has a password reset, it is usually written once and rarely revisited, and it hands out account access by design. That combination puts it near the top of any tester’s list. OWASP maintains a dedicated cheat sheet for forgotten password functionality precisely because the same handful of mistakes keep appearing in otherwise well built applications.
The token is the whole security control
A reset token is a temporary password, so it needs the properties of one. Testers check whether it is long and random, and they check it against a sample: tokens built from a timestamp, a sequential counter or an MD5 of the email address are still out there, and a few hundred captured samples make the pattern obvious. Lifetime matters as much as entropy. A token valid for a week is a week of exposure in any mailbox that is later compromised. Single use matters too, because a token that still works after the password has been changed lets an attacker who reads an old email take the account back.
Where the link gets sent
Host header injection turns your own reset email into a phishing message. If the application builds the reset link from the incoming Host header, an attacker requests a reset for someone else’s account with that header pointing to a server they control, and the genuine email arrives carrying a link to the attacker. Build the base URL from configuration rather than from the request. Watch the referrer as well: if the reset page loads third-party analytics or advertising scripts, the token in the address bar can leave the building in a referrer header, which is why the token should be consumed and the user redirected before anything else loads.
“The test I run first is asking for a reset on an account that does not exist. If the message differs from the one for a real account, or if it comes back noticeably faster, you have handed me a way to confirm which of a million email addresses have accounts with you. That list has resale value on its own, quite apart from what it lets us do next.”
William Fieldhouse, Director, Aardwolf Security Ltd
Rate limiting and the six digit code
Short numeric codes need strict throttling or they are simply a slow password. A six digit code offers a million combinations, which sounds adequate until an attacker can submit thousands of attempts a minute against an endpoint with no lockout. Limit attempts per account and per source, expire the code after a handful of failures, and make the user request a new one. Check the reset request endpoint too, since an unlimited request rate lets somebody flood a mailbox until the genuine warning is buried. Where the flow runs through a mobile client, the same checks belong in API penetration testing rather than only in the browser.
What happens after the password changes
Changing a password should end every other session, and often it does not. Test it directly: sign in from two browsers, reset the password in one, and see whether the other still works. If it does, an attacker who has taken an account keeps it after the owner does the one thing they were told to do. The same applies to API tokens and remembered devices. Notify the user by email when a reset completes, including the time and rough location, because that message is how account takeovers get reported early. Full coverage of these paths belongs in web application penetration testing servicesrather than a scan, since no scanner can hold two sessions and compare them.
Frequently asked questions about password reset security
These questions come up whenever a development team reworks authentication.
Are security questions acceptable as a fallback?
Not on their own. Answers are often public or guessable, and they age badly. If you must keep them, treat them as a second factor rather than as a way to bypass the email step.
Should the reset page say whether an account exists?
No. Return the same message and the same timing either way. Users cope with a neutral message, and it removes a reliable way of enumerating your customer base.
