How a Simple URL Parameter Made Products Free - The $2,000 Logic Flaw That Broke an E-Commerce Site

Disclaimer:
This article is an educational analysis of a real-world bug bounty finding originally reported by another security researcher.
It aims to raise awareness about logic flaws in e-commerce systems.
All testing described here was done in authorized programs under responsible disclosure.

🧩 Introduction - When a URL Parameter Turns into a Money Printer

Sometimes, cybersecurity doesn’t start with fancy payloads or zero-days - it starts with a curious mind and a single parameter.

This story highlights one such case: an e-commerce platform where a single API parameter - id_product_feature_set - allowed products worth €699.99 to be purchased for €0.00.
The vulnerability wasn’t about SQL injection or authentication bypasses. It was about trust - the backend trusting a value it should have never trusted.

The researcher who uncovered it earned a $2,000 bounty. But the real value of this finding lies in what it teaches us about broken business logic and server-side validation failures - two of the most overlooked risks in modern web security.

🎯 Setting the Scene - A Typical E-Commerce Target

The vulnerable application was a large e-commerce platform (name withheld) where users could browse, customize, and purchase products such as electronics and software licenses.
Each product page displayed prices dynamically based on selected features - for example, choosing “Pro Edition” might change the base price.

The platform used AJAX-based background requests to calculate totals and display live pricing.
From a user’s perspective, it was a smooth, modern shopping experience.
From a hacker’s perspective, it was a playground for hidden parameters.

The researcher decided to explore these behind-the-scenes requests using Burp Suite - the golden standard for intercepting and analyzing web traffic.

🕵️ Step 1 - Reconnaissance & Observation

The investigation began with passive recon.
While browsing the store, the researcher noticed a pattern in requests triggered by price changes and “Add to Cart” actions.

One of these requests looked suspiciously verbose - it contained dozens of parameters like product_calendar_date, quantity, and others typically not shown to users.

Within this request was one parameter that caught the researcher’s eye:

GET /en/cart/add?quantity=1&product=116&product_calendar_date=1761429600&id_product_feature_set=0&product_note_needed_text=

At first, it looked harmless - just another internal configuration.
But in bug hunting, harmless-looking parameters are where the real gold hides.

💡 Step 2 - The Hypothesis

Parameters like id_product_feature_set usually tell the server which set of options (color, size, model, etc.) the customer selected.
In many systems, the backend retrieves the price from a table based on this ID.

The thought process went like this:

“If this parameter controls which product variant is loaded, what happens if I change its value?”

A simple but powerful question - and the key to discovering one of the most impactful logic flaws in e-commerce.

🧪 Step 3 - The Experiment

The researcher modified the request manually in Burp Repeater and changed the id_product_feature_set value to unexpected inputs.

Examples tested:

id_product_feature_set=-1
id_product_feature_set=null
id_product_feature_set=99999

After forwarding the modified requests, all responses returned 200 OK, meaning the server accepted them.

The next step was to check the cart page to confirm if the manipulation had any real impact.

And then came the shocker - the €699.99 product now showed as 0.00 EUR.

The product could be added to the cart and proceed all the way to checkout at zero cost.

⚙️ Step 4 - The Backend Logic Breakdown

To understand how this was possible, let’s reconstruct what the backend might have looked like.

1️⃣ Query Failure → Default to Zero

If the backend ran something like:

SELECT price_modifier FROM product_feature_set WHERE id = -1;

and the query returned no rows, it might have triggered a fallback:

if (!$feature_price) $feature_price = 0;
$total_price = $base_price + $feature_price;

Result: Zero value product.

2️⃣ Array Index Out-of-Range

If feature prices were mapped like:

$feature_price = $feature_set_prices[$id_product_feature_set];

Passing a negative or non-existent key causes PHP to return null, which when cast in arithmetic defaults to 0.

3️⃣ Business Logic Shortcut

Some legacy e-commerce systems treat invalid options as “base variant” and skip recalculation logic altogether, returning a safe default of 0 to prevent cart failure.

The result? Silent failure with free checkout.

🧨 Step 5 - Why This Is a High-Impact Vulnerability

At first glance, this might look like a simple bug - “the price didn’t load correctly.”
But from a security and business perspective, it’s catastrophic.

Here’s what makes it severe:

• Financial Loss: Users could buy paid products for free.
• Inventory Manipulation: Automated bots could mass-order zero-priced goods.
• Compliance Risk: Transactions with wrong totals can invalidate accounting logs.
• Fraud Gateway: Attackers could chain it with coupon or API misconfigurations for large-scale abuse.

Imagine thousands of “purchases” for €0 processed overnight - a nightmare for any store owner.

🧠 Beginner Breakout - What Is Parameter Tampering?

Parameter tampering is a business logic attack where the attacker manipulates hidden or client-controlled parameters to influence server-side behavior.

Common vulnerable parameters:

• price
• discount
• role
• id
• amount
• plan

Typical real-world examples:

• Changing role=user to role=admin
• Modifying discount=0 to discount=100
• Replacing price=699 with price=0

The golden rule:

Never trust values coming from the client side - even if they’re hidden or “read-only” in the UI.

💬 Step 6 - Reporting the Vulnerability

The researcher documented everything meticulously:

• The exact endpoint and modified parameter
• Screenshots showing normal vs manipulated requests
• Proof that checkout succeeded at €0
• Description of business impact

The report was submitted to the private bug bounty program.

Within a day, the triage team confirmed the vulnerability and rated it Critical (P1) under the business logic category.
The reward: $2,000 USD.

The response included a note of gratitude:

“Thank you for identifying a logic flaw that could have led to significant revenue loss. The issue is now fixed.”

🧱 Step 7 - The Fix (From a Developer’s Lens)

The developers patched the vulnerability by implementing several key safeguards.

✅ 1. Server-Side Validation

The server now verifies whether the submitted feature set ID actually belongs to the product.

if (!in_array($id_product_feature_set, $valid_feature_sets)) {
    throw new Exception("Invalid feature set ID");
}

✅ 2. Database-Level Integrity

Constraints were added to ensure relational consistency:

ALTER TABLE product_feature_set
ADD CONSTRAINT fk_product_feature FOREIGN KEY (product_id)
REFERENCES products(id);

This guarantees that a feature set cannot exist outside its product context.

✅ 3. Independent Price Calculation

Instead of relying on the client request, the total is now recomputed on the server:

price = get_base_price(product_id)
modifier = get_feature_modifier(id_feature)
total = Decimal(price) + Decimal(modifier)

✅ 4. Tamper Detection

If client-supplied prices differ from the server’s computed totals, the system logs the event and rejects the transaction.

⚔️ Step 8 - Real-World Comparisons

This bug isn’t an isolated case. Similar incidents have been reported across industries:

• 2019: A major airline’s “currency conversion” bug allowed tickets to be purchased for $0 by modifying price query parameters.
• 2021: A coupon API flaw in a retail app allowed discounts over 100%, resulting in negative totals and payouts to customers.
• 2023: A SaaS subscription platform allowed downgrading enterprise plans to free tiers by tampering with the plan ID during renewal.

Each of these cases stems from the same root cause: trusting client-side input for critical business logic.

🧩 Step 9 - Pentester’s Perspective: Detecting Such Flaws

Professional pentesters and bug hunters use both automation and intuition to find logic flaws.

🔧 Tools That Help

• Burp Suite - Intercept and replay modified parameters.
• ZAP Proxy - For open-source traffic analysis.
• ffuf or ParamSpider - Discover hidden parameters quickly.
• Autorize - Detect broken access or parameter tampering automatically.

🧭 Methodology

1. Map the App Flow: Identify where input influences backend logic.
2. Isolate Dynamic Calls: Especially during checkout, login, or role updates.
3. Fuzz IDs & Numbers: Try negative, null, and oversized integers.
4. Observe Silent Behavior: Non-errors often indicate backend miscalculations.
5. Cross-Check with Valid Data: Always compare modified and legitimate behavior.

The best bugs aren’t always visible immediately - they hide behind what doesn’t break.

🛡️ Step 10 - Defensive Perspective for Organizations

Organizations must design defense-in-depth controls to prevent such exploits:

1. Never Trust Client Data - All calculations, especially financial ones, must occur on the server.
2. Validate Everything - Use strict schema validation (e.g., JSON Schema, zod, Pydantic).
3. Add Server-Side Price Recalculation - Never accept client totals.
4. Use Centralized Pricing Engines - Avoid scattered logic across microservices.
5. Implement Audit Trails - Log all modified requests for anomaly detection.
6. Penetration Testing - Include logic flaw testing in your regular assessments.
7. Bug Bounty Collaboration - Encourage ethical researchers to help find business logic bugs before attackers do.

🧰 Step 11 - Lessons for Bug Hunters

💬 Step 12 - Broader Implications for Cybersecurity

This vulnerability proves a fundamental truth about web security in 2025:
the most damaging bugs are not always technical - they’re logical.

Attackers no longer need SQLi or RCE when they can quietly exploit broken workflows that developers never expected users to manipulate.
As systems become more API-driven, this attack surface only grows wider.

Parameter tampering, once considered a “low-hanging fruit,” is now one of the most lucrative bug classes for hunters who understand business logic deeply.

🔚 Final Thoughts - The Beauty of Simplicity

This bug wasn’t flashy. It didn’t need complex payloads or bypasses.
It was found by thinking critically and testing the edges of what’s “supposed to be safe.”

The researcher’s $2,000 payout wasn’t just a reward - it was a recognition of how simple curiosity can expose million-dollar risks.

In cybersecurity, sophistication isn’t always in the exploit - sometimes, it’s in the observation.

So next time you see a hidden ID or feature flag in a request, ask yourself:
“What happens if I just… change it?”

🧾 References

• OWASP Testing Guide: Business Logic Vulnerabilities
• PortSwigger Web Security Academy - Parameter Tampering
• HackerOne Reports - Logic Flaws in E-Commerce Systems
• Bugcrowd University - API and Logic Testing Essentials

Published on herish.me - advancing web security education through real bug bounty research and responsible disclosure.