OWASP Insecure Design
Insecure Design is A04 in the OWASP Top 10 and was added in 2021 to address a root cause that other categories miss. The vulnerabilities covered in this course so far — injection, misconfiguration, broken authentication — can often be patched after the fact. Insecure design cannot. It describes a system where the architecture itself contains flaws. No amount of patching fixes a fundamentally broken blueprint.
The Bridge Analogy
A construction team builds a bridge designed for foot traffic and then opens it to heavy trucks. Reinforcing the surface does not fix the problem — the foundation was never engineered for that load. Security patches on an insecurely designed application work the same way: they treat symptoms while the structural flaw remains.
The Difference Between Insecure Design and Implementation Bugs
Implementation bug (fixable with a patch): A developer forgets to add a permission check on one API endpoint. Fix: Add the check. Insecure design (requires rethinking the architecture): The system was designed so that every user shares a single session token. No patch fixes this — the token model must be redesigned from scratch.
Real-World Insecure Design Examples
Password Reset via Security Questions
Designing a password reset flow around secret questions assumes the answers are truly secret. In practice, "mother's maiden name" and "first pet" are findable through social media. The entire design is flawed, not just one implementation detail.
No Rate Limiting in the Architecture
A system designed so that one user can trigger unlimited automated requests gives attackers a free tool to enumerate data, brute-force codes, and cause denial of service. Adding rate limits later — after millions of lines of code depend on unlimited requests — is expensive and incomplete.
Single-Factor Admin Access
A design that says "admins log in with a password" never included MFA as a requirement. When this becomes a compliance or audit issue later, retrofitting MFA into an existing authentication flow can take months of engineering work.
Mixing Data Tiers
An architecture where the public-facing web server queries the database directly — with no application layer in between — means a compromise of the web server immediately gives the attacker direct database access. Designing separate tiers with controlled access paths limits blast radius.
How Insecure Design Develops
Product team skips threat modeling before development starts
|
v
Design documents contain no security requirements
|
v
Developers build features quickly without security constraints
|
v
Security review happens at the end (or not at all)
|
v
Application goes live with structural weaknesses baked in
|
v
Patching individual bugs does not fix the underlying architecture
Threat Modeling: Designing Security In
Threat modeling is a structured exercise done before coding starts. The team asks: "What could go wrong? Who might attack this? What do they gain? How do we stop them?"
The STRIDE framework identifies six threat categories: S Spoofing — Attacker pretends to be someone else T Tampering — Attacker modifies data R Repudiation — Attacker denies performing an action I Information Disclosure — Attacker reads private data D Denial of Service — Attacker makes the system unavailable E Elevation of Privilege — Attacker gains higher access rights For each component in the design, the team asks: "Which STRIDE threats apply here, and how does our design address them?"
Secure Design Principles
Defense in Depth
Layer multiple independent security controls so that if one fails, others continue to protect the system.
Layer 1: WAF blocks malicious requests at the network edge Layer 2: Input validation rejects bad data at the application Layer 3: Parameterized queries stop injection at the database Layer 4: Least-privilege DB account limits damage if Layer 3 fails
Fail Securely
When a component errors or crashes, it should default to a safe state — not an open one. A failed permission check should deny access, not grant it.
Separation of Privilege
Require more than one condition to be met for sensitive operations. Example: transferring large amounts of money requires both authentication and a second approval from a different employee.
Economy of Mechanism
Keep security-critical designs as simple as possible. Complex systems have more places where things can go wrong.
How to Embed Secure Design in Your Process
1. Perform Threat Modeling Before Every Feature
Spend one to two hours on threat modeling at the design stage of every significant feature. Identify attack paths and build controls into the design before writing code.
2. Write Security Requirements, Not Just Functional Requirements
Every feature specification should include explicit security requirements. "Users can reset their password" should come with: "via a time-limited, single-use email link, with no more than 3 attempts per hour."
3. Use Established Design Patterns
Use well-reviewed patterns for authentication, authorization, session management, and data access rather than building custom solutions. The OWASP Application Security Verification Standard (ASVS) provides design-level security requirements for each of these areas.
4. Conduct Design Reviews with Security Input
Include a security engineer or trained developer in design review meetings. Security concerns raised at the design stage cost a fraction of what they cost to fix after deployment.
Quick Prevention Checklist
[✓] Threat modeling completed before development starts [✓] Security requirements written alongside functional requirements [✓] Defense-in-depth layers specified in the architecture [✓] Fail-secure defaults for every error condition [✓] Design reviewed by someone with security knowledge
Key Takeaway
Insecure design cannot be patched away. Security must be built into the architecture from the first design decision. Threat modeling and explicit security requirements are the tools that make this possible.