There’s a class of security vulnerability that doesn’t require a sophisticated attacker. No zero-days, no exploit chains, no nation-state tooling. Just a developer who made a reasonable-sounding shortcut at 2am, and an attacker who knows to look for it.
Trusting client-side flags in a password reset flow is one of those shortcuts. It’s also one of the most dangerous mistakes you can make, because it hands over account takeover capability to literally anyone who can open a browser’s developer tools.
Let’s dig into how this actually breaks.
The Setup: What “Trusting the Client” Looks Like
Imagine a typical password reset request. User submits their email, clicks “Send Reset Link,” and the frontend fires off something like this:
POST /api/reset-password{ "email": "victim@email.com", "is_verified": true}The is_verified: true field is the problem. The intent was probably innocent – maybe the developer added it so the backend could skip a database lookup, or it was left over from an earlier design where the frontend handled verification. Whatever the origin, the server is now reading a flag from the client and trusting it as gospel.
If the backend logic says something like “if is_verified is true, proceed to reset the password,” then any attacker who intercepts or replays this request can just… set it to true. For any email. For any account.
The attacker doesn’t need the victim’s password. They don’t need access to the victim’s inbox. They just need to know the victim’s email address – which is often public, or easily guessable, or obtainable from a dozen different data breaches.
Breaking It: Exactly What an Attacker Does
This is not a theoretical attack. The steps are trivial.
Open any intercepting proxy such as Burp Suite is the standard, but even the browser’s built-in network tab with some fetch manipulation gets you there. Send a legitimate reset request for your own account. Watch the request. You’ll see the body.
Now modify it:
{ "email": "ceo@targetcompany.com", "is_verified": true}Forward it. If the backend trusts is_verified, the server processes the reset. A token gets generated and sent (or worse, the password is reset immediately). The attacker controls the account.
No phishing. No social engineering. No special knowledge about the target beyond their email address.
The reason this is so insidious is that it can pass basic security reviews. The developer thinks “we validate on the frontend before sending this request.” That’s true. But frontend validation protects against honest mistakes from legitimate users. It does nothing against someone who is deliberately crafting requests.
The client is not your security layer. It never was. The moment you send data to a user’s browser, that data is under their control. Full stop.
Unlock the full post here: [Your Password Reset Is Broken – And You Probably Don’t Know It – The CyberSec Guru]
Exclusive Access: This entire series will be available exclusively to my Buy Me a Coffee members! Join now for as low as $2/month and get lots of benefits and exclusive content.
Exclusive for Buy me a Coffee members!
Join for as low as $2/month and get access to this post of the series where we make an entire OS from scratch and other exclusive member-only posts!
