The flow nobody tests: password reset

Password reset is the flow you built once, tested once, and never touched again. You do not use it, because you know your password. But the customers who do hit it are, by definition, already locked out and already frustrated, and if the reset also fails, they are gone. It is a small flow with an outsized cost, and it depends on the two least reliable things in your stack: email delivery and single-use tokens.

Where password reset quietly fails

Reset is a chain of steps across systems, and every link breaks in its own way.

• The email never arrives. The whole flow depends on an email landing in an inbox within a minute or two. A misconfigured sending domain, a spam filter, a hit quota, or a degraded email provider means the customer clicks "reset," waits, and gives up. Nothing in your app logs a failure, because from your side the email was handed off successfully.
• The token is broken. Reset links carry a token that has to be valid, unexpired, and single-use. A bug in how it is generated, encoded into the URL, or checked on the way back in means the link 404s, says "invalid or expired," or silently does nothing. Long links also get mangled by email clients that wrap or rewrite URLs.
• The reset does not actually take. The form accepts the new password, shows a success message, and the old password still works, or the new one does not. Now the customer is more confused than when they started.
• The security edges are wrong. A reset flow should not reveal whether an email has an account, should expire and invalidate tokens properly, and should not let a used link be replayed. These are easy to get subtly wrong and hard to notice by hand.
• The landing after reset is dead. After setting a new password, the customer should end up logged in or at a clear login prompt, not on a blank page or an error.

What good coverage looks like

A real password-reset test follows the whole chain, in a real browser, the way a locked-out customer does:

1. Request a reset for a real address and confirm the request is accepted.
2. Confirm the email actually arrives, and that the reset link in it works.
3. Follow the link, set a new password, and confirm the success state.
4. Confirm the new password logs you in and the old one no longer does.
5. Watch the console and network the whole time, so a failed request behind a "success" screen is caught.

The email step is the one most tests skip and most flows break on. If your test does not confirm the message actually lands and the link actually works, you are testing half a flow.

How VeriWasp fits

A VeriWasp playtest drives the reset the way a real user does, in a real browser: requests the reset, and can check that the email and its link resolve, follows it, sets a new password, and confirms the account is usable again. It captures the console and network throughout, so a reset that shows "success" while the request behind it failed comes back as a finding, not a pass.

Run it on a schedule as well as on deploy, because email delivery degrades on its own timeline, with no deploy to trigger a check. You can test your own reset flow with a few free runs, no card required.

Nobody thinks about password reset until it is the only thing standing between a paying customer and their account. Test the flow you hope no one needs, because the people who need it have no patience left.