Misinterpretation of Input

The application correctly receives input but interprets its meaning incorrectly - parsing it as the wrong data type, applying the wrong character encoding, or misreading a delimiter - leading downstream logic to act on a different value than what was actually intended by whoever (or whatever) sent it. The input itself isn't malformed; the application's understanding of it is wrong.

This is an application-specific parsing/interpretation bug requiring detailed knowledge of exactly how the target's own parsing logic is supposed to work, to identify the case where its actual behavior diverges - not a generic testable signature.

Manual testing with edge-case and boundary-value inputs across every parsing/interpretation point, comparing the application's actual downstream behavior against its intended interpretation.

Tip: There's no generic payload or scanner signature for a logic flaw by definition — the request is technically valid, so finding these requires someone who already understands the specific workflow's intended rules deliberately trying to violate them, which is squarely a manual-testing and design-review exercise rather than an automatable one.

Real-World Impact

A business-logic or secure-design flaw abuses the legitimate, intended workflow of an application in a way its designers didn't anticipate, without tripping any conventional technical control — no injection, no broken access control in the classic sense, just the rules of the workflow itself being incomplete. Applying the same one-time discount code twice by reordering checkout steps, skipping a required approval stage by calling a later endpoint directly, or manipulating a multi-step form to submit a lower price than the UI ever actually offered are all textbook examples.

Because these flaws violate rules that are specific to the application rather than a generic technical pattern, the impact is directly tied to what the workflow controls — a flaw in a checkout flow means direct financial loss, a flaw in an approval workflow means bypassed governance, a flaw in a matching or allocation system means unfair or exploitable outcomes for other users.

This category also tends to be undervalued by purely technical security reviews, since the code involved is often working exactly as written — the defect is in what was written, not how it was implemented, which means it requires someone who understands the product's actual intent to recognize it as a bug at all.

Prevention and Secure Design

Preventing Misinterpretation of Input takes a defense-in-depth approach — no single control below is sufficient alone, but together they close off both the primary path and the most common bypasses.

Enforce every business invariant server-side, explicitly. A rule like "a discount code can only be used once" needs to be checked and enforced by server-side state, not implied by the order the UI happens to present steps in.

Threat-model the workflow during design, not after launch. Walk through each multi-step flow asking "what happens if a user calls these steps out of order, repeats one, or skips one" as part of design review, before it ships.

Treat every endpoint as independently reachable. Never assume a step will only be called in the sequence the UI presents — an attacker can and will call any endpoint directly, in any order, with any parameters.

Log and monitor for logic-level anomalies, not just technical attack signatures. A traditional WAF or scanner won't catch a legitimate-looking request that violates a business rule — that requires monitoring built around the specific invariants that matter to the product.

Test with someone who knows the product's intent, not just its code. A tester who understands what the workflow is supposed to prevent can deliberately try to break those specific assumptions in a way a generic technical review won't.