<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Wansu</title>
    <description>The latest articles on DEV Community by Wansu (@wansu379).</description>
    <link>https://dev.to/wansu379</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4010561%2Fe03a1954-4b8a-43b2-9444-920a728096b7.jpg</url>
      <title>DEV Community: Wansu</title>
      <link>https://dev.to/wansu379</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/wansu379"/>
    <language>en</language>
    <item>
      <title>Price Manipulation via Product ID Mismatch in Checkout API (IDOR)</title>
      <dc:creator>Wansu</dc:creator>
      <pubDate>Wed, 01 Jul 2026 08:36:18 +0000</pubDate>
      <link>https://dev.to/wansu379/price-manipulation-via-product-id-mismatch-in-checkout-api-idor-2c4n</link>
      <guid>https://dev.to/wansu379/price-manipulation-via-product-id-mismatch-in-checkout-api-idor-2c4n</guid>
      <description>&lt;p&gt;&lt;strong&gt;Category: Business Logic Vulnerability / Broken Access Control (OWASP A01:2021)&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Summary&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Initial Challenge — Bypassing Payload Encryption&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Ftz65jke5cb75cuafgtk2.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Ftz65jke5cb75cuafgtk2.png" alt=" " width="800" height="758"&gt;&lt;/a&gt;&lt;br&gt;
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.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Steps to Reproduce&lt;/strong&gt;&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;Add a low-priced product to cart to initiate a legitimate checkout flow.&lt;/li&gt;
&lt;li&gt;Intercept the checkout/order request using Burp Suite Repeater.&lt;/li&gt;
&lt;li&gt;Decrypt the payload using the IV and key obtained from the client-side inspection.&lt;/li&gt;
&lt;li&gt;Modify the decrypted payload:

&lt;ul&gt;
&lt;li&gt;Replace product_id with the ID of a high-value product.&lt;/li&gt;
&lt;li&gt;Keep the price/total field unchanged (still reflecting the low-priced product).&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;Re-encrypt the payload using the same IV and key, then send the manipulated request to the server.&lt;/li&gt;
&lt;li&gt;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.&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;&lt;strong&gt;Root Cause&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Impact&lt;/strong&gt;&lt;/p&gt;

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

&lt;p&gt;&lt;strong&gt;Recommendation&lt;/strong&gt;&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Never trust client-side price/total values. All pricing calculations should be performed server-side using the product_id as the source of truth.&lt;/li&gt;
&lt;li&gt;Implement server-side validation that recalculates the total based on verified product data before processing payment.&lt;/li&gt;
&lt;li&gt;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.&lt;/li&gt;
&lt;li&gt;Add anomaly detection/logging for mismatched price-product combinations.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;&lt;strong&gt;Lessons Learned&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Tools Used&lt;/strong&gt;: Burp Suite (Repeater, Proxy), Chrome DevTools (chrome://inspect/#devices) and CyberChef&lt;/p&gt;

</description>
      <category>api</category>
      <category>backend</category>
      <category>cybersecurity</category>
      <category>security</category>
    </item>
  </channel>
</rss>
