Never trust the client with your Stripe price

I was reading a Stripe tutorial last week and watched the author write amount: req.body.amount. That single line lets any user buy Premium for $1. It's also a common pattern in Stripe Checkout starter code. This post is about why, and how to make it impossible.

The setup

You're building a paywalled product. You wire up Stripe Checkout, follow a popular tutorial, ship it. Looks great. Tests pass. Users are paying.

Six months later, someone opens DevTools, edits the request body, and pays €1 for your Premium plan. Your Stripe dashboard shows a successful charge. Stripe doesn't validate your business logic. It charged what it was told to charge. Your database shows a Premium subscription. Your billing logic is doing exactly what you wrote.

This is price tampering. It happens at the one line where the server decides what to charge.

The vulnerable pattern

Here's the shape of the bug. Paraphrased from a tutorial I won't link. You've seen this shape before:

// app/api/checkout/route.ts (don't do this)
export async function POST(req: Request) {
  const { priceId, amount, plan } = await req.json();

  const session = await stripe.checkout.sessions.create({
    mode: "payment",
    line_items: [
      {
        price_data: {
          currency: "eur",
          product_data: { name: plan },
          unit_amount: amount, // attacker controls this
        },
        quantity: 1,
      },
    ],
    success_url: `${origin}/success`,
    cancel_url: `${origin}/cancel`,
  });

  return Response.json({ url: session.url });
}

The frontend POSTs { priceId: "premium", amount: 2999, plan: "Premium" }. The server passes amount straight into Stripe. Stripe charges what it's told.

Exploiting this needs nothing fancy:

curl -X POST https://yoursite.com/api/checkout \
  -H "Content-Type: application/json" \
  -H "Cookie: session=..." \
  -d '{"priceId":"premium","amount":100,"plan":"Premium"}'

amount: 100 is €1.00 in cents. Attacker gets a Stripe Checkout link for €1, completes the payment, and your post-checkout webhook hands them Premium.

The same bug shape applies to priceId if you trust it from the client:

// Also bad. Trusting which price the client picked.
const { priceId } = await req.json();
const session = await stripe.checkout.sessions.create({
  line_items: [{ price: priceId, quantity: 1 }],
  // ...
});

If your "Hobby" plan's priceId is price_xxx_5eur and your "Enterprise" plan's priceId is price_xxx_500eur, an attacker swaps the value in the request body and pays €5 for Enterprise.

Why this keeps happening

Three reasons it slips through.

1. Most Stripe tutorials are demos. They want to show you Stripe in 50 lines of code, so they wire the frontend straight to the checkout endpoint. Demos become starter templates. Starter templates become production code.

2. The bug looks like working code. Real users complete real payments. Until somebody opens DevTools, you have no signal that anything is wrong. Logs, dashboards, webhooks, all green.

3. Stripe gives you both APIs. price_data (inline price definition) and price (reference to a Price object) live side by side in their docs. Inline price_data has legitimate uses (true dynamic pricing, donations, marketplace splits). But it's the same shape as the vulnerable pattern, so the bug hides in plain sight.

The fix in one rule

The client tells you which plan the user wants. The server decides what that plan costs.

That's it. Implementation:

// app/api/checkout/route.ts (server-determined pricing)
const PLANS = {
  hobby: { priceId: process.env.STRIPE_PRICE_HOBBY },
  premium: { priceId: process.env.STRIPE_PRICE_PREMIUM },
  enterprise: { priceId: process.env.STRIPE_PRICE_ENTERPRISE },
} as const;

type PlanKey = keyof typeof PLANS;

export async function POST(req: Request) {
  const { plan } = (await req.json()) as { plan: PlanKey };

  // 1. Validate the plan key against a server-side allowlist
  if (!Object.hasOwn(PLANS, plan)) {
    return new Response("Invalid plan", { status: 400 });
  }

  // 2. Look up the priceId server-side. Never accept it from the client.
  const { priceId } = PLANS[plan];

  const session = await stripe.checkout.sessions.create({
    mode: "subscription",
    line_items: [{ price: priceId, quantity: 1 }],
    success_url: `${origin}/success`,
    cancel_url: `${origin}/cancel`,
  });

  return Response.json({ url: session.url });
}

The client sends { plan: "premium" }. That's the most they can influence. The mapping from "premium" to a real, server-controlled priceId is unforgeable. If the attacker sends { plan: "free_lifetime" }, the allowlist check rejects it. If they send { plan: "premium", amount: 100 }, the amount field is ignored. It doesn't exist in the server's logic.

For genuinely dynamic amounts (donations, custom one-off charges), you compute the amount on the server from inputs you've validated:

// Dynamic amount, still server-determined
const { donationCents } = await req.json();

if (
  typeof donationCents !== "number" ||
  donationCents < 100 ||
  donationCents > 100000
) {
  return new Response("Invalid amount", { status: 400 });
}

const session = await stripe.checkout.sessions.create({
  mode: "payment",
  line_items: [
    {
      price_data: {
        currency: "eur",
        product_data: { name: "Donation" },
        unit_amount: donationCents,
      },
      quantity: 1,
    },
  ],
  // ...
});

The user can choose the amount, but only within bounds you've defined. They can't pass unit_amount: 1 if your minimum is 100.

How to verify you don't have this bug

A two-minute self-audit:

# 1. Open your /pricing page. Click your most expensive plan.
#    Watch the Network tab when you hit "Subscribe" or "Buy".

# 2. Find the request to your checkout-create endpoint. Copy it as cURL.

# 3. Replay it with a tampered body. Change priceId, amount, plan name,
#    quantity, anything money-shaped:
curl -X POST https://yoursite.com/api/checkout \
  -H "Content-Type: application/json" \
  -H "Cookie: <your auth cookie>" \
  -d '{"plan":"premium","priceId":"price_FAKE","amount":1,"quantity":-1}'

# 4. Check the response. If you got a Stripe Checkout URL, open it.
#    If the price shown is anything other than your real plan price, you have a bug.

If the resulting Stripe Checkout page shows the correct, original price regardless of what you sent, you're safe. If it reflects the tampered fields, patch before you do anything else.

Three more places the same bug hides

Once "the server owns money-shaped values" clicks for you, you start seeing it everywhere.

1. Quantity. Same bug, different field. quantity: -1 in older Stripe versions caused weird negative-amount behavior. Validate quantity bounds explicitly.

2. Coupon / promo codes from client. If you let the client say "apply coupon XYZ," the server has to verify XYZ is real, active, and applies to this plan for this user. Never just pass it through.

3. Customer ID. If the client sends { customerId } to attach the checkout to an existing Stripe customer, an attacker can swap their customerId for someone else's. Always derive customerId from the authenticated session on the server.

The pattern: anything that influences money or attribution comes from authenticated server state, not from the request body.

The principle

Stripe is one of the safer payment APIs because it pushes you toward the right patterns most of the time. But it can't enforce "client doesn't send money values". That's on your code. The same principle applies anywhere the client shouldn't have authority: authorization roles, feature flags, internal IDs, prices, plan tiers, expiration dates.

Think of a request body as a wish, not a fact. The server decides what to grant.

I run MatchResume.ai, a B2C SaaS with token-based pricing. Exactly the kind of product where this bug would have been embarrassing. The pattern above is what I wish every Stripe tutorial led with, instead of saving it for a footnote.

If you ship paid features and you've never tampered your own checkout request as a test, do it tonight. Two minutes, one curl, real peace of mind.

推荐订阅源

DEV Community