business-logic

Business Logic Detection

Overview

A business logic flaw is a defect in how the application enforces its own rules, so an attacker can steer it into a state the designers never intended. There is no dangerous API to grep for: the input is well-formed and the code does exactly what it was written to do — the rule it encodes is wrong, incomplete, or enforced in the wrong place. These flaws live in server-side decision logic, after input is parsed and before the state change is committed, wherever the application decides what a request is allowed to do to money, inventory, entitlement, or workflow state. The attacker is an ordinary user, authenticated or not, sending requests the front end would never produce: a negative amount, a removed parameter, a step out of order, an order mutated after a discount was granted. What they gain is goods without paying, value created from nothing, a limit exceeded, or a state they should not occupy. This skill finds such flaws by locating the decision points where a domain rule should be enforced, checking each one in parallel, and merging the results into <output_dir>/business-logic-results.md.

What it is NOT

• Access control (/websec:access-control): a missing or wrong permission check on a resource or function. Test: if the fix is "check that this caller owns this object / holds this role", it is access control. Here the caller is entitled to use the function; the rule the function encodes is what fails.
• Race conditions (/websec:race-conditions): if the flaw needs two overlapping requests and disappears when requests are processed one at a time, it is a timing flaw. Test: can you describe an exploit as a single ordinary sequence of requests? If yes, it stays here.
• Property binding (/websec:api): setting isAdmin or price because the framework auto-binds every body field is mass assignment — the mechanism belongs to /websec:api. Judge here when the field is legitimately accepted but the value is never validated against the domain rule.
• Injection (/websec:sql-injection, /websec:os-command-injection, /websec:ssti): those need input reaching an interpreter. A logic flaw needs no metacharacters; the payload is semantically abusive, syntactically ordinary.
• GraphQL operation limits (/websec:graphql): a limit defeated by aliasing or batching many operations into one document is a missing operation limit in the executor and belongs there. Test: would the rule still break under a single plain REST call? If yes it is here; if the abuse needs GraphQL's own batching, it is theirs.
• Information disclosure (/websec:information-disclosure): a verbose error or debug page is disclosure on its own. It is evidence here only when it reveals a rule that a request can then defeat.
• Authentication (/websec:authentication): the login, registration, reset and multi-factor state machine is theirs, including a step that can be skipped, reordered, or replayed to arrive at an authenticated state — that skill owns every route to a session that was never legitimately issued. Guessable codes split by what the code stands for: one that substitutes for a credential (reset link, verification code, one-time factor) is theirs; one that carries value but no identity (coupon, referral, gift card, invite) is judged here. Workflow sequencing outside the credential flows — checkout, refunds, approvals — is this skill's.
• Not a finding: client-side validation that the server also enforces; an odd response or truncated value with no money-, entitlement-, or security-relevant consequence; a rule deliberately relaxed and documented as such in architecture.md; an admin-only tool with no path from an ordinary user.