Reliance on Untrusted Inputs in a Security Decision

A security-relevant decision - whether to authenticate a request, whether to authorize an action, how much to charge, which role to grant - is made based on a value the client controls and could have tampered with, rather than a value the server independently derives or verifies. This is a broad category that specific patterns like Modification of Assumed-Immutable Data and Client-Side Enforcement of Server-Side Security are narrower instances of.

Confirming this requires knowing, application by application, which specific inputs feed which specific security decisions - there's no generic technical signature, since the exact same client-controlled value is completely benign in most contexts and only a bug where the server specifically fails to re-validate it before a security-relevant decision.

Manual testing informed by tracing the application's actual data flow - identifying which values reach security decisions and testing whether the server independently verifies each one rather than trusting the client-supplied copy.

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 Reliance on Untrusted Inputs in a Security Decision 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.