Business Logic — Offensive Testing Methodology

Business Logic — Offensive Testing Methodology

Business logic flaws are the highest-paying class of vulnerability for bug bounty and the hardest for scanners to detect. They live in the gap between what the developer specified and what an attacker can convince the system to accept.

Quick Workflow

1. Map every multi-step flow as a state machine (states + allowed transitions + side effects)
2. For each transition, ask: who can call it, in what state, with what inputs, how many times
3. Probe each axis (state, identity, input, frequency) for assumptions
4. Combine flaws — single-axis flaws are usually low severity; chains are critical
5. Quantify financial impact per finding (loss-per-attack × scale)

Reconnaissance — Mapping the Logic

Build the State Machine

For each user flow, draw:

• States: cart, pending payment, paid, shipped, refunded, cancelled
• Transitions: which API/UI action, which role, which preconditions
• Side effects: balance change, inventory change, email, webhook

Look for transitions that:

• Skip intermediate states (cart → shipped without paid)
• Are reversible when they shouldn't be (shipped → cart)
• Trigger side effects more than once
• Allow cross-role invocation

Hidden / Internal Endpoints

# Compare authenticated and unauthenticated JS bundles for buried admin routes
diff <(curl https://app/main.js) <(curl -H "Cookie: ..." https://app/main.js)

# Look for flag/feature toggles that change UI but not server-side enforcement
grep -E '(isAdmin|isInternal|featureFlag|debug)' bundle.js

# API spec (OpenAPI/Swagger) often lists endpoints the UI never calls
curl https://app/api/openapi.json | jq '.paths | keys'