Insecure Design
A fundamental weakness in how the system is designed, not just a bug in the implementation.
What is Insecure Design?
This is the category most different from the rest. Insecure design isn't a bug in the code but a flaw in the plan: a security control that was simply never there to begin with. The code can be perfect and bug-free, yet still insecure because the flow never accounted for how people would abuse it. You can't patch a flawed design by fixing a single line. Try the business-logic example in the demo tabs.
Business logic abuse
Many insecure designs are business-logic abuses: vouchers that stack without limit, negative quantities that produce a 'refund', transfers that run twice via a race condition, or password resets through easily guessable questions. These functions 'work as coded', but can be bent because reasonable limits were never designed in.
The fix: design security in from the start
The defense is a process, not a patch. Do threat modeling: ask 'how could this feature be abused?' at the design stage. Define clear business rules and enforce them server-side, use secure design patterns, and write abuse cases, not just use cases. Security planned from the start is far cheaper than one bolted on later.
Impact
Because the root cause is in the design, the impact often hits the business directly: financial loss, fraud, mass feature abuse, and gaps that can't be closed without redesigning. Precisely because it doesn't look like a 'bug', insecure design often slips past code review and automated scanners.