Price Tampering: When the Server Trusts a Client-Supplied Price
The challenge
Here is the checkout request the shop sends when you buy item #42. Look closely: the price you are about to be charged is sitting right there in the request, and the server trusts it. Lower the price, send the order, and read the confirmation note the response leaks.
What you'll learn
- Recognize a client-side price-trust flaw where the amount charged is read from a request parameter
- Tamper a single numeric field in a captured checkout request and replay it
- Read an HTTP/JSON response to confirm the lower price was actually charged
- Explain why prices and other money-relevant values must be re-derived server-side from a trusted source
- Distinguish input validation (rejecting bad shapes) from authority (deciding what a value should be)
Skills tested
Prerequisites
- Basic understanding of HTTP requests, query parameters, and JSON bodies
- Familiarity with the idea of a shopping cart and a checkout flow
How it works
A price-tampering flaw is a business-logic vulnerability: the application puts a money-relevant value - the price the buyer will be charged - inside a request the buyer controls, and the server treats that value as the source of truth. Because every byte of a request travels through the browser and any proxy the user runs, the buyer can simply rewrite price=4999 to price=1 before the request is sent. The server charges what it was told, and the order completes at a price the merchant never set.
The subtle part is that this is not an injection or an authentication bug. The session cookie is valid, the field is a perfectly well-formed number, and nothing is malformed. The mistake is one of authority: a price is a server-side fact that belongs to the catalog, keyed by the item id. The request should say which item the buyer wants and how many, never how much it costs. When the server lets the client name the price, it has handed control of its revenue to the attacker.
This shape appears anywhere a client-supplied number is trusted for a money or quantity decision: discounts, shipping fees, loyalty points, currency, and tax. The reliable fix is the same in every case - look the value up from a trusted store on the server and ignore whatever the client sent.
Common mistakes
- Assuming the price shown in the request is fixed by the server, when it is just a number in the request body that anyone can rewrite before sending.
- Reaching for special characters or injection payloads instead of noticing that a plain, editable number decides what you are charged.
- Setting the price to
0and giving up when the server rejects it - the validation only enforces a minimum of 1, so the smallest accepted value is 1. - Treating this as bad input validation rather than the real flaw: the server should never have accepted a price from the client at all.
How to defend against it
Never read a price, discount, fee, or any money-relevant amount from a request parameter, body field, or hidden form input. On the server, look the item up by its id from your trusted catalog or pricing service, compute the total there, and charge that - the request may only describe what the user wants to buy, never what it costs.
- Derive the unit price server-side from the item id and your pricing store; discard any client-supplied price field.
- Recompute the order total, taxes, and shipping on the server at checkout time, then reconcile against the payment authorization.
- Validate quantity and item id as well, and reject orders whose computed total does not match the amount actually authorized.
- Log and alert when a request carries a price that disagrees with the catalog, so tampering attempts are visible.