Business logic vulnerabilities
Model allowed workflow states and transaction invariants, then test repeated, reordered, and concurrent actions that remain syntactically valid.
What it means
Business logic vulnerabilities let callers misuse a workflow while sending syntactically valid requests. Problems include skipping steps, reusing one-time benefits, or exploiting inconsistent assumptions between services. Detection requires understanding the intended business rules rather than searching only for malformed technical input.
A practical example
A checkout workflow must verify the current price, stock, and payment state before shipping. The team tests reordered and repeated requests to ensure an earlier successful step cannot authorize an unrelated or changed later transaction.
What to check
Model the workflow states and allowed transitions. Verify ownership, prerequisites, limits, concurrency behavior, and the effect of retries. Document which invariants must remain true across services.
A common pitfall
A request can pass input validation and still violate the business process. A vulnerability scanner usually cannot infer all of an organization's intended commercial rules.
Think it through
Can a valid payment callback be reused to authorize a second order?
Answer: The application must bind it to the intended transaction and handle duplicates without granting new benefits.
A workflow contains promises
Imagine a fictional academy issues a certificate only after required assessments are complete. The invariant is a business rule: the learner must satisfy the prerequisites before issuance. Valid JSON and a correctly authenticated account do not establish that condition.
Define the states and transitions explicitly. The service should evaluate the current authoritative state when performing the sensitive action, not rely solely on a browser having displayed the expected sequence.
Repetition and concurrency change the test
Suppose a one-time course credit can be redeemed through two requests arriving together. Each request might pass an individual check before either updates the shared state. The intended rule must hold for the combined result, not only a sequential happy-path test.
Retries create a related question: a repeated confirmation should not create a new entitlement unless the business design allows it. Bind approvals and payment or completion evidence to the intended transaction.
Review the boundary between services
One service may record completion while another issues certificates. Their assumptions about freshness, ownership, and failures must agree. A stale cached state or partial operation can create inconsistent outcomes even without malformed input.
For a safe paper exercise, draw enrollment, assessment, eligibility, and certificate issuance as states. Add skipped, repeated, and concurrent transitions, then state which must be rejected or handled idempotently. Use invented learners and no real payments. Explain what evidence demonstrates the final business effect. This turns an abstract vulnerability category into specific invariants that developers and testers can verify together.
Related concepts
References & further reading
Original explanations, with primary references for deeper study.
OWASP: Business Logic Security