Direct answer
Business logic testing checks whether application workflows preserve their intended rules, including order, eligibility, one-time effects, and ownership. Write the expected invariant, exercise controlled state transitions, and verify the resulting record or entitlement rather than only the page response.
Write the invariant in plain language
Examples include one reward per eligible event, no report before verified payment, and no approval by the requesting user. Ask the product owner which outcomes must never occur. A broken user journey is a correctness issue; a security finding needs a rule failure with meaningful unauthorized impact.
- Identify the actor, resource, prerequisite, and allowed outcome.
- Use sandbox transactions and disposable entitlements.
- Record which state transitions the owner authorizes you to exercise.
Review server-side workflow state
The server needs to validate prerequisites and state transitions independently of page order. Inspect what happens when a completed action is repeated or a stale step is submitted. Sensitive effects need durable protection against unintended replay.
Reference: OWASP Business Logic Security Cheat Sheet.
Exercise bounded alternate sequences
For a sandbox purchase, test cancellation, a repeated confirmation, and a return after session expiry. Verify which record becomes paid and which account receives the credit. Keep real charges, repeated financial transactions, and high-volume concurrency outside this fixture plan.
- Check persisted outcomes after each approved sequence.
- Use a normal completed journey as the positive control.
- Restore fixtures and record cleanup at the end of testing.
Fix the rule and its regression cases
Choose a repair at the layer that owns the invariant, such as the transaction or authorization boundary. Test the original failure sequence alongside ordinary retries and valid user flows. A UI disabled button alone cannot enforce a server-side one-time effect.
Assessment limits
A tester cannot infer every business rule from the interface. Real-money, concurrency, or third-party side effects need a separate approved plan. A generic automated scan often lacks the state fixtures needed to assess product-specific invariants.
Frequently asked questions
Can a workflow be insecure without an injection bug?
Yes. Incorrect eligibility, ownership, ordering, or repeated effects can create unauthorized outcomes even when input is well formed.
Does a disabled button prevent repeated actions?
It improves the interface but does not enforce the rule at the server. The action endpoint and stored state need to handle repeats correctly.
How should a business logic finding describe impact?
State the violated rule and the unauthorized result demonstrated with test fixtures. Avoid claiming financial loss or account takeover that the evidence did not establish.
Primary sources and further reading
These guides combine published security guidance with practical assessment planning. Adapt checks to the owner's policy, environment, and authorized scope.