How to fix Business Logic Abuse

What an attacker can do

The concrete impact of leaving Business Logic Abuse unpatched.

How to fix Business Logic Abuse

5 ordered steps. Apply them in order — each builds on the previous.

1. 1

   Server-authoritative pricing — never trust client price

   Client sends item IDs and quantities. Server looks up prices from database, calculates total. Never accept price as input.

   Sounds obvious; it isn't. Many React-style apps pass full cart objects (with prices) as the source of truth. Don't.

   javascriptStep 1

   // ❌ Trusting client price
   app.post("/checkout", async (req, res) => {
     const { items } = req.body;  // [{id, qty, price}]
     const total = items.reduce((sum, i) => sum + i.price * i.qty, 0);
     await stripe.charges.create({ amount: total * 100, ... });
   });
   
   // ✅ Server-authoritative price
   app.post("/checkout", async (req, res) => {
     const { items } = req.body;  // [{id, qty}]
     const products = await Product.find({
       _id: { $in: items.map(i => i.id) }
     });
     const productMap = new Map(products.map(p => [p.id, p]));
   
     let total = 0;
     for (const item of items) {
       const p = productMap.get(item.id);
       if (!p || !p.active) return res.status(400).send("Invalid item");
       if (item.qty <= 0 || item.qty > 100) return res.status(400).send("Invalid qty");
       total += p.price * item.qty;
     }
     await stripe.charges.create({ amount: total * 100, ... });
   });

2. 2

   Allow-list updatable fields (no mass assignment)

   When users PATCH a resource, accept only explicitly allowed fields. Never spread req.body into your model.

   Mass assignment is the source of 'PATCH /users/me with role=admin' privilege escalation.

   pythonStep 2

   # ❌ Mass assignment — user can set ANY field
   @app.patch("/users/me")
   def update_me(updates: dict):
       user = current_user()
       for k, v in updates.items():
           setattr(user, k, v)  # role=admin, balance=999999, ...
       user.save()
   
   # ✅ Explicit allow-list
   ALLOWED = {"name", "email", "avatar_url", "timezone"}
   
   @app.patch("/users/me")
   def update_me(updates: dict):
       user = current_user()
       for k, v in updates.items():
           if k not in ALLOWED:
               continue  # silently drop, or return 400
           setattr(user, k, v)
       user.save()
   
   # Better: use a Pydantic schema with strict fields
   class UserUpdate(BaseModel):
       model_config = {"extra": "forbid"}
       name: Optional[str] = None
       email: Optional[EmailStr] = None
       avatar_url: Optional[HttpUrl] = None
       timezone: Optional[str] = None

3. 3

   Use server-side state machines for workflows

   Define explicit state transitions. Order can go pending → paid → fulfilled. Reject any other transition.

   Don't accept arbitrary status updates. Status changes should happen as a side-effect of business events (Stripe webhook = transition to paid; warehouse API = transition to fulfilled).

   javascriptStep 3

   const VALID_TRANSITIONS = {
     pending: ["paid", "cancelled"],
     paid: ["fulfilled", "refunded"],
     fulfilled: ["returned"],
     cancelled: [],
     refunded: [],
     returned: [],
   };
   
   async function transitionOrder(orderId, newStatus, source) {
     const order = await Order.findById(orderId);
     const allowed = VALID_TRANSITIONS[order.status] || [];
     if (!allowed.includes(newStatus)) {
       throw new Error(`Cannot transition ${order.status} → ${newStatus}`);
     }
     // Plus: only certain sources can trigger certain transitions
     if (newStatus === "paid" && source !== "stripe_webhook") {
       throw new Error("Only Stripe can mark orders paid");
     }
     order.status = newStatus;
     await order.save();
   }
   
   // API endpoints don't directly accept status changes
   // app.patch("/orders/:id") rejects any status field

4. 4

   Idempotency keys for money-affecting operations

   If the user submits the same checkout twice (double-click, network retry), don't charge twice. Require Idempotency-Key header.

   Stripe and most payment APIs support idempotency natively. Use the same pattern internally for refund, transfer, charge endpoints.

   javascriptStep 4

   // Express middleware — require + verify idempotency key
   async function idempotency(req, res, next) {
     const key = req.get("Idempotency-Key");
     if (!key || !/^[a-f0-9-]{32,64}$/.test(key)) {
       return res.status(400).json({ error: "Idempotency-Key required" });
     }
   
     const cached = await redis.get(`idem:${key}`);
     if (cached) {
       return res.status(200).json(JSON.parse(cached));
     }
   
     // Capture response
     const orig = res.json.bind(res);
     res.json = (body) => {
       redis.setex(`idem:${key}`, 86400, JSON.stringify(body));
       return orig(body);
     };
     next();
   }
   
   app.post("/charge", idempotency, chargeHandler);

5. 5

   Rate-limit business actions per user/account

   Coupon abuse, referral fraud, trial extension — all involve repeated actions. Per-user limits stop them.

   Different from per-IP rate limiting (which catches DoS). This is per-account: 'one trial per user', 'one referral redemption per user', 'max 5 coupon uses per day'.

   pythonStep 5

   from datetime import datetime, timedelta
   
   def can_redeem_coupon(user_id: int, coupon_id: int) -> bool:
       # Per-user, per-coupon: only once
       existing = CouponRedemption.query.filter_by(
           user_id=user_id, coupon_id=coupon_id
       ).first()
       if existing:
           return False
       # Daily cap — per user, max 5 coupons / day
       today_count = CouponRedemption.query.filter(
           CouponRedemption.user_id == user_id,
           CouponRedemption.redeemed_at >= datetime.utcnow() - timedelta(days=1)
       ).count()
       return today_count < 5
   
   def redeem(user_id: int, coupon_id: int):
       if not can_redeem_coupon(user_id, coupon_id):
           raise ValueError("Coupon limit reached")
       db.session.add(CouponRedemption(user_id=user_id, coupon_id=coupon_id))
       db.session.commit()