Module 4 · Business Logic — Where Scanners Fail

Last updated: April 29, 2026

Business logic bugs are where scanners fail and pentesters earn their fee. They’re not about malformed input — the input is well-formed. They’re about intended features being used in combinations or sequences the developers didn’t model. This module teaches you to see the game rules of an application so you can find moves the designers didn’t anticipate.

Why this happens

Developers model the “happy path.” They write the test suite for the happy path. Reviewers approve the happy path. QA validates the happy path. Nobody models the entire state space, because the state space is exponential in the number of features. Business logic bugs live in state combinations — a sequence of legal actions that together produce an illegal outcome.

Classic example: coupon + refund. Each feature is fine in isolation. Together: use coupon, get discount, refund original item, keep the discounted second item. Each step is an allowed action. The combination nets free merchandise. No scanner finds this. No test case covers it until someone thinks to write it.

How these bugs emerge

Three archetypes:

1. Missing state transitions

The app models states (pending → confirmed → shipped → delivered) but doesn’t enforce the transition graph. Attacker jumps from pending to delivered with a crafted request. Classic in e-commerce, finance workflows.

2. Concurrent combinations

Two actions that are safe sequentially but produce exploitable state when concurrent. Race-condition-flavoured but at business-logic level. Promo code redemption by 50 parallel requests. Transfer from account to itself with timing.

3. Trust accretion

Actions that increment trust without checkpoints. Referral → give bonus. Referred user completes signup → give bonus to referrer. Attacker can refer themselves (one account for two identities) or chain referrals without real activity to farm bonuses. The system trusted the accumulation of legitimate-looking events.

Why we look

Because these bugs map directly to revenue loss in fintech, e-commerce, gaming, and SaaS — the classes of applications with real-money stakes. A business logic flaw that lets users transfer funds without authorization, apply unlimited discounts, or drain loyalty points becomes a direct P&L impact. Reports that identify these class of bugs get executive attention where technical-only reports don’t.

For red-team engagements, business logic is where non-detection-generating compromise lives. Exploiting an SQL injection makes noise. Using the app’s own features to achieve unauthorized outcomes is invisible to most defensive tooling.

What we find

• Workflows that don’t enforce state transitions (skip approval, skip verification, skip payment)
• Refund + coupon + cancellation combinations that yield net negative
• Promo code usage outside intended cohort (new-user-only codes used by existing users)
• Referral / loyalty programs with self-reference, circular chains, or inactive-account farming
• OTP or MFA flows that accept the “resend” loop to brute-force without rate limits
• Shopping cart price manipulation where the client sends price and server trusts it
• Booking systems that allow overlapping reservations or negative-duration bookings
• Subscription workflows with trial stacking, plan downgrade abuse, mid-cycle credit gaming
• Voting / rating systems that count IP, cookie, and user identity as three separate votes each
• Tournament / game mechanics where score accumulation is faster than the honest-user rate

How to find them

Understanding the product like the product manager:

1. Map the user journeys. What does each user type want to do? What are the steps?
2. Identify the money / trust edges. Where does value enter and exit? Coupons, balances, scores, points, referrals
3. List the state machines. Orders, subscriptions, sessions, bookings — their legal transitions, their invariants
4. Ask: “What does the business explicitly NOT want?” “Users shouldn’t stack trials indefinitely.” Then try to stack trials
5. Combine two features. What happens if refund meets coupon? What happens if cancellation meets partial shipment?
6. Try sequences out of order. Call step 3 before step 2. Call step 1 twice. Pause halfway and pick up later
7. Try boundary values. Zero quantity. Negative amount. Maximum integer. Empty string where required.
8. Bypass client-side gates. If the UI hides a button or option, check if the API serves it

Why automated scanners miss these

Scanners don’t understand semantics. They see endpoints and parameters, not “order” and “coupon” and “cannot-both-apply.” The only way to find business logic bugs is to understand the business, which means reading product documentation, using the app as a user, and thinking “what would a profit-seeking adversary do?”

This is also why business logic testing scales poorly with automation and requires senior pentest time. Pay accordingly; scope accordingly.

Defender perspective

Business logic is where threat modeling earns its keep. For every new feature:

• Explicit list of “what this feature should never allow”
• Tests that attempt to violate each invariant
• Monitoring / anomaly alerts for outputs that shouldn’t occur (balances going negative, coupons used N times when max was 1)
• Reconciliation jobs that detect inconsistencies after the fact

The threat model is not “what external attacker could do?” It’s “what legitimate user motivated by fraud would do?”

Mindset takeaway

Stop testing inputs. Start testing outcomes. The question isn’t “is this input safe?” — it’s “could any sequence of legitimate-looking inputs produce an outcome the business doesn’t want?” The pentester who asks that question finds bugs the scanner never will. And the engineer who asks that question at design time ships a safer feature.