Scanners miss business logic flaws because the requests look valid. Nothing in the traffic says a price should not change after checkout starts. Only someone who knows the business rules can say so. QA engineers are well placed to test these, using abuse cases and state based test design.
What a business logic flaw is
A business logic flaw is a gap between what the application allows and what the business intends. The code works as written. The written rules are simply incomplete.
OWASP's Web Security Testing Guide says automated tools are incapable of detecting logical vulnerabilities and find it hard to understand context, so a person has to perform these tests. Its examples include returning to a summary page in a valid session and changing an item's price before completing a purchase, and cancelling a loyalty transaction after points were added to see whether the points still count.
None of these requests is malformed. A scanner sees a normal HTTP call with a normal response code.
Why QA is a good fit
The guide tells testers to develop abuse and misuse cases and to borrow techniques from functional testers, especially logical and finite state testing. That is routine QA work: model the states, list the transitions, then try the ones that should not exist.
QA also tends to know the process end to end. The guide notes that this testing depends on the tester's knowledge of the full business process and its rules, and that talking to the client or developers helps when intent is unclear.
A repeatable method
- List the business rules for the flow in plain sentences. "A coupon applies once." "A refund cannot exceed the amount paid." "A cancelled order releases stock."
- Draw the states: cart, paid, shipped, refunded, cancelled.
- Mark the allowed transitions. Everything else is a candidate test.
- For each rule, write the attacker version. "Replay the coupon request twice at once."
- Run the checks by hand first, then automate the stable ones as negative tests.
- Record the rules you could not confirm and ask the product owner, rather than guessing.
Examples of rules worth testing
| Rule | Attempt that should fail |
|---|---|
| A price is fixed at checkout | Edit the price field in the request |
| Steps run in order | Jump from step 1 straight to step 3 |
| A refund cannot exceed payment | Request a larger refund |
| A cancelled item gives no points | Cancel after points were added |
On the skipped step case, the guide asks what happens when a user goes from step one directly to step three: does the application fail open, deny access, or return an error? Write the expected answer into the test.
What to hand off
Tools still help around the edges. A dynamic scan covers injection, headers and exposed files, and an API scan covers schema and authentication gaps. Those complement logic testing rather than replace it. Keep each tool for what it finds and give the logic cases to people.
When you report a logic defect, include the rule that was broken, the exact sequence of steps, and the business effect. Developers cannot fix a rule they do not know exists.
Try it yourself
Click through it at your own pace, or open it full screen. Note which kinds of problems the scan reports, then compare them with the rules in your own checkout flow.
For the parts tools can cover, Safeguard offers a free scan with dependency and SBOM findings, plus policies and gates in CI. Your business rules still need your own tests.
Quick check
Can any tool find business logic flaws?
Tools can help with parts of the work, such as replaying sequences, but the OWASP guide says a person who understands the process has to do these tests.
Who should own these tests?
QA and product together, with security reviewing the abuse cases. Developers add the stable ones as automated tests.
Sources
Last reviewed: 19 October 2026.
