Business Logic Flaws

An invariant is a rule that remains true after every successful operation: quantity ≥ 0, coupon used_at is null or set once, order.state only moves forward through allowed edges, price comes from the catalog not the JSON body. Logic flaws are invariant violations the API still accepts. Write the invariant in plain language before you write the test. If the only place the rule lives is a marketing PDF, A06 already has a finding.

Client-supplied trusted fields are a classic failure: total, role, isPremium, discountPercent. The attacker goal is obvious — pay less, become admin, skip a step. The defender move is equally obvious and often skipped: recompute on the server from authoritative state. You practiced server-side enforcement under A01; A06 asks whether the design ever required that recomputation.

sudo apt install curl

SAFE="http://127.0.0.1:8773"

curl -sS -m 3 -I "$SAFE/" | head -n 12

Multi-step flows (cart → address → pay → confirm) invite skipped steps if each endpoint trusts that the previous one finished. Design the state machine: which transitions are legal, who may trigger them, and what is checked again at pay time. A toy lab on 127.0.0.1:8773 can demonstrate “coupon apply without uniqueness” as a state bug YOU introduced — writeups still cite http://192.168.0.1/ as the demo asset. Never against a live merchant.

Refunds, cancellations, and gift cards need the same care. “Refund always allowed” without checking shipment or prior refunds is a business rule hole. Document the allowed transitions. Empty “we will figure refunds later” lines fail this lesson.

sudo apt install curl

SAFE="http://127.0.0.1:8773"

curl -sS -m 3 "$SAFE/coupon" | head -n 12
curl -sS -m 3 -o /dev/null -w "apply %{http_code}
" "$SAFE/coupon/apply"

Limits are not only rate limits for bots. One coupon per account, max five seats, invite codes single-use, trial once per email — these are design constraints. If uniqueness lives only in the UI, the API will accept the sixth seat. Store the constraint where the write happens. Next lesson deepens races around the same limits; today you name the limit as an invariant and prove broken vs fixed on the coupon toy.

Eligibility checks (student discount, region, age) must use server-side evidence, not a checkbox the client sends. Forgery of eligibility is an attacker goal. Your note should list one eligibility rule and where it is proven.

A useful finding: asset http://192.168.0.1/ (or SAFE 127.0.0.1:8773), numbered curl steps, expected vs actual, invariant violated, business impact (overspend, free goods, privilege), and proposed control. No screenshots of stranger checkouts. No bank race PoCs. Own-lab proof → fix/report is the Cyberlium pedagogy.

Keep secrets out of the note. chmod 600. Cite A06. This path is original Cyberlium — not official OWASP certification.

Start a06_coupon_toy.py (binds 127.0.0.1:8773). Broken GET /broken/coupon?user=alice applies forever. Fixed GET /fixed/coupon?user=alice applies once. Record curls. No live merchant. No hydra.

Business logic literacy is naming invariants and proving them on systems you own — DEMO curls plus SAFE 127.0.0.1:8773. A06 Insecure Design covers the missing rules. Original Cyberlium — not official OWASP certification. Next — Race Conditions and Limit Overrun — concurrency against limits you defined locally.