Business logic flaw
In application security, a business logic flaw is a defect in what the application permits rather than in how it is coded. Every request is well formed and every technical control works; the attacker simply uses the workflow in an order, quantity or combination the designers never considered, and the application agrees.
How it works
There is no unsafe function to grep for and no malformed input to reject, because there is nothing malformed. The attacker studies what the application is trying to achieve and then breaks an assumption it never wrote down: that a step happens before another step, that a value cannot be negative, that a discount is used once, that a price sent by the client matches the catalogue, that a refund cannot exceed the payment, that two requests will not arrive at the same instant.
Finding them is a modelling exercise. You enumerate the states an object can be in, the transitions the interface offers, and then you attempt the transitions the interface does not offer but the server still accepts. That is why the useful input is documentation, a walkthrough with the product owner, and threat modelling, not a payload list.
What goes wrong
These flaws survive because scanners cannot see them. A scanner recognises patterns that are wrong in general. Whether an order may ship before payment clears is only wrong in the context of this business, and no tool has that context. This is the clearest measurable argument for manual testing: the categories a tool covers well and the categories it cannot cover at all are different sets, and this one is entirely in the second.
What we recover in practice is money and privilege. Applying a voucher concurrently so the redemption check passes twice is a race condition in the logic. Skipping the payment step by requesting the confirmation route directly. Changing an identifier in a multi-step flow so the last step acts on someone else’s object, which is where this meets IDOR. Completing a registration flow with the email verification step omitted, which ends in account takeover.
Where this shows up in an audit
The finding is written as a sequence of requests, in order, with the resulting state of the record, because a single request proves nothing here. We state the assumption that was broken in plain language, since that is what the fix has to restore, and the fix is almost always a server-side check at a specific transition rather than input validation. Severity is measured in what the flaw is worth per execution and whether it can be repeated. This is part of why our web testing is done by hand rather than by scanner.