Never Trust the Browser for Price: Checkout Amount Tampering

This is one of the oldest bugs on the web and it keeps reappearing, because the code that produces it is the code an assistant writes when you ask for a checkout. "Take the cart total and post it to /api/checkout" is a perfectly natural sentence, and it describes a vulnerable design.

What "hidden" means

The confusion is entirely in the word. type="hidden" is a rendering instruction — do not paint this on screen. It is not a security boundary, it is not encrypted, and it is not read-only. The value is in the HTML the visitor already has.

<!-- What you wrote -->
<form action="/api/checkout" method="post">
  <input type="hidden" name="amount" value="4900">
  <input type="hidden" name="currency" value="usd">
  <button>Pay $49.00</button>
</form>

Right-click, Inspect, double-click the value, type 1, press Enter, click Pay. That is the entire attack. It needs no tooling, no knowledge, and no particular intent — people find this by accident.

The JavaScript version is identical in substance and only slightly less obvious:

// Same problem, different shape
const res = await fetch('/api/create-payment-intent', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ amount: cartTotal, currency: 'usd' }),
})

Anyone can set a breakpoint before that call and change cartTotal, or copy the request as cURL from the Network panel and re-send it with any number they like. Nothing about the request is authenticated as coming from your own code, because there is no such thing.

Check your own checkout

1. Load your checkout page and view the page source. Search for type="hidden" and read every field. Anything named amount, price, total, cost or similar is the pattern in this article.
2. Open the Network panel and complete a checkout up to the point of payment. Look at the request payload your app sends to its own API.
3. Ask one question of each field: if a customer changed this, would the server notice? Not "would they think to" — would it notice.
4. If you use Stripe, check whether you create a PaymentIntent with an amount taken from the request body, or with a price looked up server-side.

It is worth being precise about what you have found. An amount arriving from the browser is not proof of an exploitable flaw — a server that ignores it and recomputes the total from its own catalogue is perfectly safe, and plenty do. What it proves is that the safety depends entirely on server code that nothing outside can see. That is why ShipReady rates a checkout amount built in the browser as medium rather than critical: it reports the observable fact and tells you where to look, rather than asserting a consequence it cannot verify.

The fix: identifiers in, amounts never

Stop accepting an amount. The browser sends what the customer is buying; the server decides what that costs.

// Client: says what, never how much
await fetch('/api/create-payment-intent', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ priceId: 'price_1AbCdEf', quantity: 2 }),
})

// Server: looks the real price up, ignores anything else it was sent
const { priceId, quantity } = await req.json()

const price = await stripe.prices.retrieve(priceId)
if (!price.active) throw new Error('inactive price')

const qty = Number.isInteger(quantity) && quantity > 0 && quantity <= 10 ? quantity : 1

const intent = await stripe.paymentIntents.create({
  amount: price.unit_amount * qty,
  currency: price.currency,
})

Note that quantity is still validated. Moving the price server-side closes the obvious hole and leaves the arithmetic — a negative or absurd quantity is the next thing someone tries, and a quantity of -1 against a positive price has produced real refunds on real sites.

Stripe, Paddle and Polar all hold a product catalogue on their side precisely so you can pass an identifier instead of a number. Using it is less code than the vulnerable version, not more.

The stronger option: do not build the checkout

A hosted checkout — Stripe Checkout, a Paddle overlay, a Polar link — removes the whole class of problem. You create a session server-side with line items you control, and the customer is sent to a page you do not render. There is no client-side amount to tamper with because there is no client-side amount. For most small products this is the right answer, and the reason to build a custom flow should be a specific requirement rather than a default.

The other half: fulfilment

Getting the charge right does not help if you grant access on the wrong signal. Two rules:

• Never fulfil on a redirect to a success URL. Anyone can navigate to /success?paid=true directly. It is a page, not a proof.
• Fulfil on a verified webhook. Your provider signs the event; verify that signature server-side before acting on it, and treat the event as the only source of truth about whether money moved.

This is also why a webhook signing secret must never reach the browser. If it does, the signature proves nothing — ShipReady reports an exposed Stripe webhook secret as its own finding.

Discount codes belong on the server too

The same principle, one step sideways. A discount table compiled into your JavaScript bundle is readable by anyone who opens the Sources panel — no guessing required — so the codes you meant for one campaign or one partner are effectively public. And if the browser is the thing applying the discount, the code is not even needed to pay less.

The browser should send only the string the customer typed. Your server, or your payment provider’s promotion-code feature, decides whether it is valid and what it is worth. ShipReady reports discount codes compiled into the bundle at high severity for the leak alone, independent of whether the discount is applied client-side.

While you are in the checkout

• Confirm the page and its form action are both HTTPS. A payment form that posts over plain HTTP is reported as insecure payment form transport, and a mixed-content page undermines the padlock the customer is relying on.
• Confirm you are not collecting card numbers into your own DOM. Raw card fields in your page pull you into a far heavier PCI DSS scope than using your provider’s hosted fields — ShipReady flags raw card fields in the page.
• Confirm the site is not in test mode, which is the other way for a working-looking checkout to take no money.

How ShipReady detects this

ShipReady reads the HTML and JavaScript your checkout pages actually serve. It reports a price submitted from a hidden form field when it finds one posting to a payment endpoint, and an amount built in the browser when client-side code sends an amount-shaped value to a checkout endpoint. Each finding names the field and the endpoint it saw.

It never submits your forms and never attempts a transaction — every finding is read from the page, which means you can reproduce all of it yourself with developer tools in a few minutes. Scan your site free to check your own checkout, or see the full list of payment checks.