Day 17 of breaking web applications on purpose.
Let's play a quick thought experiment.
Imagine opening a banking app and you type:
Transfer ₹100 → send.
But what if…
The app lets you decide which account the money comes from?
Not your account.
Any account.
That's exactly what I tested today.
🎯 The Setup
The application has a Money Transfer feature.
Simple form.
Amount Sender ID Recipient ID
Looks normal.
You fill the fields → press transfer → money moves.
But security testers don't trust forms.
We trust requests.
So I intercepted the transfer request before it reached the server.
Inside it, I saw something interesting:
transfer_amount=100 recipient_id=2 sender_id=3
Wait.
Why is the sender_id coming from the client?
That number decides who pays.
Let's test something.
🧠 The Experiment
Instead of sending money from my account…
I changed the request.
From:
sender_id=3
To:
sender_id=1
Someone else's account.
Then I hit Send.
💣 The Result
Transfer successful.
The server accepted the request.
Money moved.
But not from me.
From another user.
No authorization check. No ownership validation. No security barrier.
Just a number change.
⚡ Why This Works
The application trusted the client.
It assumed:
"If the request says sender_id = X, then the user must own that account."
But the client is under user control.
Requests can be edited.
Parameters can be changed.
Numbers can be manipulated.
And that's how IDOR vulnerabilities happen.
🧠 Think About This
Imagine walking into a bank and saying:
"Please withdraw ₹10,000 from account #102."
And the bank replies:
"Sure!"
Without checking if you actually own it.
That's basically what this application did.
🔥 Why This Is Serious
An attacker could:
• Transfer funds from other users • Drain balances • Manipulate financial data • Abuse payment logic • Destroy trust in the system
And the scariest part?
This wasn't a complex exploit.
It was editing one parameter.
🛡️ The Fix
Never trust client-supplied identifiers.
Instead:
• Derive the sender account from the authenticated session • Ignore client-provided account IDs • Validate ownership on the server • Enforce authorization checks on every transaction
Security rule:
If the client controls the account ID, the attacker controls the money.
🎯 Day 17 Takeaway
Today's exploit didn't involve malware.
It didn't involve SQL injection.
It didn't require admin access.
Just a modified request.
One number changed.
And suddenly…
I could transfer money from someone else's account.
Tomorrow?
We keep pushing IDOR further.
Because when applications trust the client…
Attackers write the rules.
LESS GOOO 🔥
If the client decides who pays, the attacker decides who loses.