Day 18 of breaking web applications on purpose.
Let me ask you something!
When you update your address on a website who decides which address gets updated?
You?
Or the server?
Because today I discovered something interesting.
Sometimes it's just a number.
🎯 The Setup
The application has an Address Entry feature.
Users can update their saved address information.
Street City Zip code Submit.
Simple profile update.
Normal functionality.
But before sending the request to the server, I intercepted it.
Inside the request was this parameter:
addressID=1
That number tells the server which address record to update.
Now here's the real question.
What happens if we change it?
🧠 The Experiment
Instead of updating my own address…
I modified the request.
From:
addressID=1
To:
addressID=2
Another user's address.
Then I sent the request.
No special privileges. No admin account. Just a normal user.
Click.
Send.
Wait.
💣 The Result
Success.
The server accepted the request.
The address update went through.
But not for me.
For someone else.
No authorization check. No ownership validation. No warning.
Just a number changed.
And someone else's data modified.
⚡ Why This Happens
The application trusted the client.
It assumed:
"If the request says addressID = X, the user must own that address."
But the client is under user control.
Requests can be modified.
Parameters can be edited.
And attackers know exactly where to look.
This is another example of IDOR — Insecure Direct Object Reference.
🧠 Think About This
Imagine logging into your online profile…
And discovering your address has changed.
You never touched it.
But someone else did.
Not by hacking the database.
Not by breaking encryption.
Just by changing one identifier.
🔥 Why This Matters
An attacker could:
• Modify other users' personal information • Corrupt stored data • Trigger delivery or billing errors • Manipulate user records • Damage system integrity
And again…
The attack wasn't complicated.
It was simply editing a request parameter.
🛡️ The Fix
Servers must never trust client-controlled object IDs.
Instead:
• Validate that the authenticated user owns the record • Derive ownership from the session • Enforce authorization checks on every update • Avoid exposing predictable identifiers
Security rule:
If the client chooses the object, the attacker chooses the victim.
🎯 Day 18 Takeaway
Today I didn't break encryption.
I didn't exploit SQL.
I didn't bypass authentication.
I just changed a number.
And suddenly…
Someone else's address belonged to me.
Tomorrow?
We test something even stranger.
What happens when profile data itself becomes editable?
LESS GOOO 🔥
If the server trusts the ID you send, it might trust you with someone else's data!