Order-Total Tampering at Checkout

Vulnerability class: Checkout/business-logic price manipulation
Mapped weaknesses: CWE-840, CWE-602, CWE-345

Order-total tampering happens when the server accepts a checkout amount (or discount result) directly from client-controlled input. Attackers can modify request payloads in transit and pay less than the legitimate price.

This issue is common in e-commerce and subscription systems where pricing logic partially lives in frontend code.

Executive Summary

The vulnerable pattern is:

1. Frontend calculates cart total.
2. Client sends total, discount, or line_item_price fields to checkout endpoint.
3. Backend trusts these values without recomputing from canonical data.

If the backend does not independently verify pricing and discount eligibility, attackers can purchase items below cost or even force near-zero totals.

CWE Mapping

CWE-840 — Business Logic Errors

The core failure is business workflow integrity: checkout accepts economically invalid states because business rules are not enforced server-side.

CWE-602 — Client-Side Enforcement of Server-Side Security

Security-critical controls (price calculation, discount application, offer constraints) are effectively enforced by the client, which an attacker fully controls.

CWE-345 — Insufficient Verification of Data Authenticity

Server fails to verify authenticity/integrity of financial inputs and treats user-supplied totals as trustworthy.

Typical Vulnerable Flow

A conceptual anti-pattern:

# vulnerable conceptual logic
@api_view(["POST"])
def checkout(request):
    cart_id = request.data["cart_id"]
    total = request.data["total"]  # client-controlled

    # missing: server-side recomputation from trusted catalog + coupon policy

    charge_customer(total)
    create_order(total=total)
    return Response({"success": True})

Attackers intercept request payloads (proxy/dev tools) and set total to a lower value.

Exploitation Logic (High Level)

Only test systems you own or are authorized to assess.

A safe validation approach in staging:

1. Add known items to cart.
2. Capture checkout request.
3. Modify total, discount, or item prices before forwarding.
4. Observe whether backend accepts manipulated values.

If the order is created/charged with tampered amounts, the vulnerability is confirmed.

Why This Becomes Severe Quickly

• Attack is low complexity (simple request editing)
• Exploitation is highly automatable
• Direct financial loss is immediate
• Abuse can scale across promotions/coupons/inventory

In many environments this rates as High/Critical business risk.

Impact Scenarios

• underpayment for physical goods
• near-zero purchase of premium digital products
• repeated coupon abuse beyond policy limits
• reseller/arbitrage fraud at scale
• accounting and tax reconciliation drift

Root Cause Patterns

Common implementation mistakes include:

• trusting total from client payload
• applying coupon validation on frontend only
• checking product price from stale client cache
• missing currency/rounding normalization on server
• no replay protection for one-time offers
• no idempotency controls for payment/checkout actions

Remediation Strategy

1) Make Server the Single Source of Truth for Price

Server must recompute payable amount from:

• trusted product pricing
• authoritative cart contents
• validated coupon/promo rules
• tax/shipping logic

Never use client total as settlement authority.

2) Accept Intent, Not Financial Outcome

Client should send:

• item identifiers
• quantities
• coupon code
• shipping choice

Server should compute and return final totals.

3) Validate Coupon Business Rules Server-Side

Enforce all constraints in backend:

• expiration
• per-user limits
• category/product applicability
• stacking rules
• minimum order thresholds

4) Bind Checkout Snapshot to Payment Session

Generate server-side signed checkout session/cart snapshot and verify it at payment confirmation.

5) Recalculate at Finalization (TOCTOU Protection)

Before order creation and before capture/settlement, recalculate again using current trusted data.

6) Add Idempotency and Replay Defenses

Prevent repeated use of one-time discounts and duplicate charge/order state transitions.

7) Instrument Security Monitoring

Alert on:

• large delta between client-submitted and server-calculated totals
• repeated failed promo validations
• unusual purchase volume with high-discount combinations

Secure Design Pattern

# secure conceptual flow
@api_view(["POST"])
def checkout(request):
    cart = get_cart_for_user(request.user)
    pricing = pricing_service.compute(
        cart=cart,
        coupon=request.data.get("coupon"),
        shipping_option=request.data.get("shipping_option"),
    )

    # optionally compare and ignore client hint fields
    # client_total = request.data.get("total")

    payment = create_payment_intent(amount=pricing.final_total)
    order = create_order_from_pricing(cart, pricing)
    return Response({
        "order_id": order.id,
        "amount_charged": pricing.final_total,
    })

Key principle: financial authority is server-only.

Testing Recommendations

Negative tests

• modified client total should be ignored/rejected
• tampered discount percentage should fail
• altered line-item price should not affect final charge

Property/business tests

• total always equals deterministic server recomputation
• coupon cannot exceed configured bounds
• subtotal, tax, and shipping invariants hold for random cart states

Integration tests

• checkout and payment confirmation use same trusted pricing basis
• one-time promo tokens cannot be replayed

Hardening Checklist

• Backend recomputes totals for every checkout
• Client-provided financial fields are ignored or verified as hints only
• Coupon validation lives in backend policy service
• Signed checkout snapshot/session validated at payment confirmation
• Replay and idempotency controls in place
• Monitoring for pricing anomalies and promo abuse

Detection Ideas for Existing Systems

Create analytics and alerts for:

• abs(client_total - server_total) > threshold
• high frequency of extreme discount baskets
• repeated checkout attempts with modified totals
• promotion usage concentrated on a small user/device cluster

Final Takeaway

Order-total tampering is not a cryptography problem first; it is a trust-boundary and business-logic problem. If the client can influence financial outcomes without strict server recomputation and verification, fraud is inevitable.

To fix it, treat checkout as a server-governed transaction: compute, verify, and enforce all price logic on the backend every time.