Automated scanners are excellent at finding many classes of technical weakness. They are much less effective at understanding whether a business process can be completed in an unintended way.
Business logic vulnerabilities exist when an application faithfully executes a technically valid request that violates the rules the business intended to enforce.
Model the workflow as a state machine
Pick a workflow such as checkout, password recovery, approval, coupon redemption, document signing, subscription changes or payout processing. Write down each state and the server-side condition required to transition to the next state.
Common attack patterns
State skipping
Attempt to call a later endpoint directly. If a request normally follows Create → Validate → Approve → Fulfil, test whether Fulfil accepts an object that never reached the required approval state.
Parameter tampering
Look for client-controlled prices, quantities, discounts, roles, approval flags, account identifiers and workflow states. The goal is not merely changing a value; it is determining whether the server recomputes the security-sensitive value from trusted state.
Replay and idempotency failures
Repeat a valid action after it should be consumed: redeem a voucher twice, reuse a one-time link, resubmit a payout request or replay an approval action. Test whether the server records the operation and enforces one-time semantics.
Race conditions
Send two or more requests concurrently around a security-sensitive transition. Examples include coupon redemption, balance updates, inventory reservation and approval workflows. A race exists when the application validates a condition and changes state in separate operations without adequate concurrency control.
Interactive workflow tester
Select an attacker strategy
Questions to ask during a pentest
- Can I reach a privileged state without completing the previous state?
- Can I perform the same action twice when the business expects once?
- Can two users collaborate to bypass a single-user control?
- Does the server recalculate sensitive values or trust the client?
- Can an expired object still be used after its state changes?
- Can I change the owner, tenant or account reference after authorization?
- Does the API enforce the same workflow rules as the web UI?
How to reduce business-logic risk
Make security-sensitive state transitions explicit on the server. Treat workflow state as trusted server data, use transaction boundaries for critical operations, implement idempotency where actions must be one-time, and authorize each state transition rather than only the initial request.
Further reading
OWASP API Security guidance includes business-flow abuse among the areas that require testing beyond simple input validation. OWASP API Security — Unsafe Consumption / Business Flow Context.