Most vulnerability classes have a signature. Injection has payloads that produce recognisable responses. Misconfiguration has states a tool can compare against a baseline. Known vulnerable components have version numbers.
Business logic flaws have none of this. Every request is well-formed, correctly authenticated and individually legitimate. What breaks is the sequence, or the assumption underneath it. A scanner cannot report a flaw it has no way to recognise, and no rule can encode “this workflow was supposed to happen in a different order”.
This is the class that separates a penetration test from a vulnerability scan, and it is where a tester who has spent time understanding your product outperforms one who has not.
The recurring patterns
State and workflow bypass
A multi-step process — registration, checkout, approval, onboarding — where each step is protected but the transition between them is not. Skip step three and post directly to step four. The application accepts it because step four validates its own input and assumes step three happened.
The strongest version of this finding is an approval workflow where the requester can transition their own request to approved.
Price, quantity and value manipulation
Negative quantities producing credits. Currency confusion where the amount is taken from the client. Discount codes that stack when they should not, apply to items they should not, or survive the removal of the item that qualified them. Rounding differences exploited across many small transactions.
Race conditions
The check and the action are not atomic. Submit the same request many times in parallel and the balance is checked before any of the deductions land. This applies to anything with a limit: single-use vouchers, invite quotas, one-time actions, seat counts, rate limits implemented in application code.
Testing this requires deliberate concurrency, which is why it is rarely found by anything other than a person who set out to look for it.
Replay of one-time actions
Password reset tokens that survive use. Email verification links that work repeatedly. Signed URLs with no expiry. Any operation intended to happen once, where nothing records that it has.
Abuse of flows designed for humans
A lookup intended for occasional individual use, automated into bulk extraction. An invite mechanism turned into a mailing tool. A search endpoint that becomes an enumeration oracle. Individually authorised, collectively a different product than you shipped.
Trusting client-side decisions
The UI hides a control, disables a field, or validates a value, and the server assumes the constraint was honoured. Anything decided in a browser or a mobile app is a suggestion.
How they are found
By understanding what the application is supposed to do, then asking what happens if it does not. There is no tooling that substitutes for this, which is why our assessments begin with reconnaissance and threat modelling rather than with a scan, and why we ask for documentation and a walkthrough.
The practical implication for scoping: a tester who is given the product’s intent — who approves what, what must happen before what, where money and entitlements move — finds materially more than one who reverse-engineers it from the interface. The time you spend in the scoping call is the highest-leverage time in the engagement.
Severity
Business logic findings are frequently the highest-impact items in a report and frequently the hardest to rate with a CVSS vector, because the vector describes technical impact and the consequence here is commercial. We rate by consequence to the business and explain the reasoning, rather than letting a vector understate a flaw that lets somebody buy your product for nothing.