Violation of Secure Design Principles

This is CWE-657's umbrella category: the system's security failed not because of an implementation bug in otherwise-sound architecture, but because a foundational design decision itself was insecure - trusting client-side validation as the sole check, relying on an unguessable URL instead of real authorization, defaulting to permissive rather than restrictive access, or baking a shared secret into a design that assumes it'll never leak. The code often does exactly what it was designed to do; the design itself is what needed to be different.

A design flaw lives in the architecture and threat model, not in a runtime code path a black-box probe can exercise. Confirming one requires understanding the intended security boundary the designers had in mind and showing it doesn't actually hold - that's an architectural judgment call, not a pattern match against traffic.

Threat modeling and architecture review during design, or a manual security assessment that maps the system's actual trust boundaries against what the design assumes, are the standard ways this class gets caught - ideally before the system is built, since retrofitting a secure design is far more expensive than reviewing one.

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 Violation of Secure Design Principles 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.