SecLab
Secure Design & Threat ModelingwalkthroughDifficulty 4/530 min

Abuse cases: the bug with no payload

Objective: After this lesson you can write abuse cases for a business flow and find bugs no scanner finds.

V2API6:2023A06:2025business-logic
Step 1 of 5 · read6 min

Using the feature in a way you never planned

Every vulnerability in the previous eight modules has a signature: a payload, an odd character, an id that is not yours, a wrong setting. The bug class in this lesson has no signature at all — every request is valid, every value is in range, and the outcome is still wrong.

Three examples, all of them requests a perfect validator waves through:

FlowThe unplanned usageOutcome
A 10% discount codeApply it to an order, cancel the order, the code is not returned but the order is refundedMoney from nothing
Transfer between two walletsTransfer a negative amount from B to AWithdrawing somebody else's money
Email change requiring confirmationChange to a new email, do not confirm, change back — if the code sets the new address immediately and merely flags it unverifiedAccount takeover via password reset

What makes this class categorically different: no tool finds it. A scanner does not know how your discount codes are meant to work; a linter does not know a negative transfer is wrong; a WAF sees POST /transfer {"amount": -1000} as entirely valid. Only somebody who understands the business finds it, and that is you.

An abuse case is a use case written from the perspective of somebody wanting to misuse it. The technique is four questions, each surfacing a different group:

QuestionThe bug group it surfaces
What if I do this step twice?Double redemption, double submit, double signing (m2-challenge)
What if I do the steps out of order?Pay before stock check, confirm before payment
What if this number is negative, zero, or enormous?Negative transfers, division by zero, overflow
What if two people do it at once?Race conditions — two requests seeing the same stale state

The first and fourth surface the most real bugs, and they are related: "twice" is the sequential version of "two at once", but their fixes differ — an idempotency key for the first, a lock at the data tier for the second.

View path

Comments

Join the discussion
Sign up to comment

Commenting needs an account with at least one completed lesson. That condition is what keeps this thread worth reading: every point belongs to someone who can be asked back, and reputation accrues over time.

Sign upSign in

You can still read every comment below without an account. Signing in brings you back to this exact spot, not to the top of the page.

Loading comments…