Price Manipulation via Product ID Mismatch in Checkout API (IDOR)

Category: Business Logic Vulnerability / Broken Access Control (OWASP A01:2021)

Summary

During security testing of an e-commerce application, I discovered that the checkout/order API endpoint did not properly validate the relationship between product_id and the corresponding price/total fields sent in the request payload. This allowed an attacker to purchase a high-value product while being charged the price of a low-value product.

Initial Challenge — Bypassing Payload Encryption

When I first attempted to intercept and modify the checkout request, I found that the payload was encrypted, making direct manipulation via Burp Suite ineffective. To understand the encryption mechanism, I inspected the application's client-side code using Chrome's remote debugging feature (chrome://inspect/#devices), which allowed me to trace how the app handled encryption on the frontend.

Through this analysis, I was able to locate the Initialization Vector (IV) and encryption key used by the application. With these values, I could decrypt the payload, modify the relevant fields (product_id and price-related parameters), then re-encrypt the payload using the same IV and key before sending it through Burp Suite Repeater.

This step was crucial — it confirmed the encryption was a client-side implementation detail rather than a true security control, since the key material was exposed and reachable from the client itself.

Steps to Reproduce

1. Add a low-priced product to cart to initiate a legitimate checkout flow.
2. Intercept the checkout/order request using Burp Suite Repeater.
3. Decrypt the payload using the IV and key obtained from the client-side inspection.
4. Modify the decrypted payload:
   • Replace product_id with the ID of a high-value product.
   • Keep the price/total field unchanged (still reflecting the low-priced product).
5. Re-encrypt the payload using the same IV and key, then send the manipulated request to the server.
6. Observe the server response: the order is created with the high-value product's name/details, but the price charged reflects the low-value product.

Root Cause

The server trusted client-supplied price/total values instead of recalculating them server-side based on the actual product_id and its price stored in the database. There was no server-side validation to cross-check product_id against the submitted price. Additionally, the payload encryption gave a false sense of security — it obscured the data in transit but did nothing to prevent tampering once the encryption scheme was reverse-engineered from the client.

Impact

• Financial fraud: Attacker can obtain expensive products while paying for cheap ones.
• Business logic bypass: Circumvents the intended pricing model entirely.
• Scalability of abuse: Could be automated/repeated across multiple orders, leading to significant financial loss.

Recommendation

• Never trust client-side price/total values. All pricing calculations should be performed server-side using the product_id as the source of truth.
• Implement server-side validation that recalculates the total based on verified product data before processing payment.
• Avoid relying on client-side encryption as a security boundary — sensitive business logic (like pricing) must always be validated and enforced server-side, regardless of payload encryption.
• Add anomaly detection/logging for mismatched price-product combinations.

Lessons Learned

This case reinforced that encryption on the client side is not a substitute for proper server-side authorization and validation. A determined tester (or attacker) can reverse-engineer client-side cryptographic implementations if the key material is reachable in the browser. It also showed the value of combining tool-based testing (Burp Suite) with manual client-side analysis (Chrome DevTools) — relying on one approach alone would not have uncovered this issue.

Tools Used: Burp Suite (Repeater, Proxy), Chrome DevTools (chrome://inspect/#devices) and CyberChef