Day 16 of breaking web applications on purpose.
Let me ask you something.
When you change your password on a website what stops you from changing someone else's?
Your login?
Your session?
Or just a number in the request?
Today I tested that question.
🎯 The Setup
There's a Change Password feature.
Simple form.
Enter a new password → submit → done.
Nothing unusual.
But security people don't trust forms.
We trust requests.
So I intercepted the password change request before it reached the server.
Inside the request, something interesting appeared:
password=newpass user_id=1
Pause.
Why is the server trusting a user_id coming from the client?
Let's test something.
🧠 The Experiment
What happens if we change that number?
Instead of:
user_id=1
We try:
user_id=2
And send the request.
No special privileges. No admin access. Just a normal logged-in user.
Click.Send.Wait.
💣 The Result
Success.
The server confirmed the password change.
But not for me.
For another user.
Just like that.
No warning. No authorization check. No verification.
One number changed.
One account compromised.
⚡ Why This Happens
The server made a dangerous assumption:
"If the request says user_id = X, it must belong to the person sending it."
But requests can be edited.
Users control the client.
Attackers control the request.
Trusting user-controlled identifiers is how IDOR vulnerabilities happen.
🧠 Think About This
Imagine a bank transfer form that asks:
"Which account do you want to withdraw money from?"
And it trusts whatever number you type.
That's basically what happened here.
Except instead of money…
It was account control.
🔥 Why This Is Dangerous
If attackers can change another user's password, they can:
• Take over accounts • Lock users out of their profiles • Access private data • Escalate privileges • Pivot deeper into the system
And the scary part?
No hacking tools required.
Just changing a number.
🛡️ The Fix
Servers must never trust client-supplied identifiers.
Instead:
• Derive user identity from the authenticated session • Ignore client-provided user_id values • Enforce strict authorization checks • Validate ownership before modifying sensitive data
Security rule:
If the client controls the object ID, the attacker controls the target.
🎯 Day 16 Takeaway
Today's exploit didn't use SQL.
It didn't use JavaScript.
It didn't use complicated payloads.
Just one modified number.
And suddenly…
Someone else's account was mine.
Tomorrow?
We push IDOR even further.
Because sometimes the biggest security failures come from the smallest assumptions.
LESS GOOO 🔥
Sometimes hacking isn't about breaking the system!
It's about realizing the system trusted you too much.