Day 20 of breaking web applications on purpose.
Let me ask you something.
When you click "Add to Cart" on an online store…
What actually tells the server which product you're buying?
The button?
The UI?
Or just a hidden parameter in the request?
Today I tested that question.
And the answer was… interesting.
🎯 The Setup
The application has a shopping cart feature.
You browse products. Click Add to Cart. The item appears in your cart.
Standard e-commerce behavior.
But security testers rarely trust what the interface shows.
We trust what the request reveals.
So I intercepted the request sent when a product was added to the cart.
Inside it was an encoded parameter that looked like this:
product_id=3
That single number decides what product the server adds to your cart.
So naturally…
I wondered what would happen if I changed it.
🧠 The Experiment
Instead of adding the product shown on the page…
I modified the request.
From:
product_id=3
To:
product_id=1
A completely different product.
Then I sent the request to the server.
No special access. No admin privileges. Just a modified parameter.
💣 The Result
The server accepted the request.
The cart updated.
And the product that appeared in the cart…
Was the one I chose, not the one shown on the page.
No validation. No verification. No restriction.
The application trusted the identifier coming from the client.
⚡ Why This Is Dangerous
The server assumed:
"If the client says product_id = X, then that must be the product the user selected."
But clients can be modified.
Requests can be intercepted.
Parameters can be edited.
Attackers don't shop through the interface.
They shop through requests.
🧠 Think About This
Imagine an online store where you could:
Add hidden products to the cart Add items not shown in the catalog Manipulate purchase logic Bypass normal purchase flows
All by editing a parameter.
That's not a UI bug.
That's a trust problem.
🔥 Why This Matters
An attacker could:
• Add restricted products • Manipulate pricing logic • Bypass product restrictions • Purchase unintended items • Abuse business logic
And once again…
The attack wasn't complicated.
Just changing an identifier.
🛡️ The Fix
Servers should never blindly trust cart parameters.
Instead:
• Validate product identifiers server-side • Ensure products are authorized and available • Implement integrity checks on cart requests • Avoid relying on client-controlled references
Security rule:
If the client controls the product ID, the attacker controls the cart.
🎯 Day 20 Takeaway
Today's exploit didn't involve SQL.
It didn't involve passwords.
It didn't involve admin privileges.
Just a modified request.
One parameter changed.
And suddenly…
The shopping cart belonged to me.
LESS GOOO 🔥
If the server trusts your cart request… you decide what gets added.