Authorization disclaimer. This walkthrough is limited to the intentionally vulnerable PortSwigger Web Security Academy lab linked below. Test only systems you own or are explicitly authorized to assess.
Overview
The POST /cart request submits both productId and price. Changing price=133700 to price=1 makes the server add the Lightweight l33t leather jacket for one cent, despite the account having only $100.

Lab objective/setup
Sign in with the supplied account and purchase the Lightweight l33t leather jacket. Its normal price is $1,337, while the available balance is $100, so the intended path cannot complete the purchase.
What I observed
The add-to-cart form sends POST /cart with a client-controlled price field. After the field was changed from 133700 cents to 1, the cart rendered the same product at $0.01 and checkout accepted the manipulated total.


Why it is vulnerable
Client-controlled price or product attributes are presentation data, not authoritative business data; the server must recalculate them.
Walkthrough in the authorized PortSwigger lab
- Log in and add the Lightweight l33t leather jacket to the cart while Burp intercepts the request.
- In
POST /cart, retain the originalproductIdand quantity but changeprice=133700toprice=1. - Forward the request and inspect the cart. It should display the jacket at $0.01 rather than $1,337.
- Proceed to checkout. The account’s $100 balance now covers the manipulated total, and the purchase completes.


Verification
The cart displays the jacket at the submitted one-cent price, checkout succeeds, and the Academy marks the exercise solved. These three states tie the result directly to the modified price parameter.

Impact and defensive lesson
A production variant enables direct revenue loss and fraudulent orders. Treat productId and quantity as requests, but load the authoritative price, discounts, tax, and inventory rules on the server and recalculate the total again at checkout.