This is a close cousin of a check I've written about before, whether disabling a user in your admin panel actually ends their active session. There's a related, equally important version worth its own test: whether a user changing their own password actually logs out every other device or browser where they were already signed in.
Why this specific scenario matters so much
Picture the most common real-world reason someone changes their password urgently: they suspect their account's been compromised, maybe they got a suspicious login alert, maybe they reused a password that just showed up in a breach elsewhere. Their instinct, and the standard advice everyone gives, is to change the password immediately. If that action doesn't also cut off whoever might already be logged in with the old credentials, the entire point of the response is undermined. The new password stops a fresh login. It does nothing about a session that was already established before the change.
How to actually test this on your own app
- Log into a test account on two different browsers, or one regular window and one private window, confirming both are actively logged in.
- From one of them, change the account's password.
- Go to the other, already-logged-in session and try performing an action or refreshing a page that requires authentication.
- If it still works without being prompted to log in again, that session survived the password change, and the whole point of changing a password in response to a suspected compromise didn't actually hold.
Why this gap exists even in apps that otherwise seem solid
The same underlying reason as the disabled-account gap I wrote about before: many session systems validate a token independently, for performance, rather than checking the full user record on every single request. A password change updates the stored password. It doesn't automatically invalidate every token that was already issued before the change, unless the app specifically includes logic to do that.
What a real fix looks like
This usually means either maintaining a way to explicitly revoke all active sessions for a user, a session store you can clear entirely on password change, or including some kind of version marker tied to the user's credentials that gets checked on every request, so a token issued before the change simply stops being considered valid the moment the password updates, regardless of whether it's technically still signed correctly.
Most password-reset advice focuses entirely on the reset flow itself, which I've also written about. This is the other half of the same story: the reset only actually protects someone if it also closes the door behind the old credentials, not just opens a new one in front.