Does the server trust the browser's price?
Everything that runs in the browser can be changed by the person using it. If the order request carries the total and the server charges that total without computing its own, anyone can pay what they like. Security testers look for this with intercepting proxies. A manual tester can check the basic case with nothing but the browser's developer tools.
Only do this on systems you are allowed to test: your own project, a test environment, or a practice site built for it, like the one linked below.
Step 1: read the order request
Open the developer tools (F12, or right-click and Inspect), go to the Network tab, and place a normal
order. Find the request that created it, usually a POST with a name like
order or checkout, and open its payload. Note what the page sends. If you see
the quantity and the product only, the server is probably computing the price itself. If you see a
total, price or discount field, keep going.
Step 2: send it again with a different total
Two ways, depending on the browser:
- Firefox: right-click the request, choose Edit and Resend, change the total in the body, and send.
- Chrome and Edge: right-click the request, choose Copy, then Copy as fetch.
Paste it into the Console tab, change the total in the
bodystring, and press Enter.
Try a few values: 0.01, 0, a negative number, and a total for a different
quantity than the one in the request.
Step 3: read the answer
| What comes back | Meaning |
|---|---|
| The order is accepted at your changed total | The server trusts the browser. A serious bug. |
| The order is accepted at the correct total | The server ignores the field and computes its own. Fine, though the field should not be there. |
| The order is rejected with a mismatch error | The server compares the totals. Also fine. |
| A server error, no explanation | Not a price bug, but worth reporting: the server does not handle unexpected input. |
Check the confirmation and any order list too: some systems accept the right amount in the response and store the wrong one.
Beyond the total
- Change the other fields too: a quantity of
-1, or a discount flag set to true when the user is not eligible. - Limits like "1 to 10 tickets" or "today or later" are often checked only on the page. Resend the request with 11 tickets or a past date.
- Look at the console as well as the network: an order response logged in full, with the customer's email in it, is a privacy bug even if the price is safe.
Writing it up
Include the original request, what you changed, what the server answered, and the charged amount. Keep it factual. "The server charged ₪0.01 for an order whose correct total is ₪244.80" is a complete finding; the developer can reproduce it in a minute.
Open the practice form
More guides: double submit · checkout totals · REST API test cases · all guides