Insecure Design

Insecure Design

One-liner: Security flaws built into the architecture from the startโ€”you can't patch a missing security control.

๐ŸŽฏ What Is It?

This is A06 of OWASP. Insecure design occurs when applications lack security controls at the architectural level. Unlike implementation bugs, these are fundamental design flaws that require re-architecture to fix.

๐Ÿ’ฅ Why It Matters (Impact)

Key Insight: Insecure design โ‰  insecure implementation. You can have secure code with an insecure design.

๐Ÿ“Š Insecure Design vs Implementation Bugs

Insecure Design Implementation Bug
Missing rate limiting on password reset SQL injection in login form
No transaction limits on transfers XSS in comment field
API allows unlimited data export Buffer overflow
No re-authentication for sensitive actions Hardcoded credentials

๐Ÿ’ฐ Real-World Example: Clubhouse

Clubhouse assumed users would only interact through the mobile app. The backend API had no authenticationโ€”anyone could query user data, room info, and private conversations directly. The "private conversation" design was fundamentally flawed.

๐Ÿ”ฌ Common Insecure Design Patterns

Pattern Risk Secure Alternative
Trusting client-side validation Bypass all checks Server-side validation
No rate limiting Brute force, scraping Rate limits, CAPTCHA
Unlimited data export Mass data theft Pagination, export limits
No re-auth for sensitive ops Account takeover Step-up authentication
Shared secrets for all users One leak = all compromised Per-user secrets
No abuse case analysis Business logic attacks Threat modeling

๐ŸŽฏ Threat Modeling (Interview Favorite!)

STRIDE Model:

Threat Description Example
Spoofing Pretending to be someone else Fake login page
Tampering Modifying data/code Changing prices in cart
Repudiation Denying actions No audit logs
Information Disclosure Exposing data Error messages with stack traces
Denial of Service Making system unavailable No rate limiting
Elevation of Privilege Gaining unauthorized access Privilege Escalation

๐Ÿ›ก๏ธ Secure Design Principles

Principle Implementation
Defense in depth Multiple security layers
Least privilege Minimal permissions by default
Fail securely Deny access on error
Zero trust Verify every request
Separation of duties No single point of compromise
Secure defaults Security out-of-the-box

๐Ÿค– AI-Specific Design Risks (2025)

Risk Description
Prompt injection User input mixed with system prompts
Blind trust in output Acting on AI decisions without validation
Model poisoning Backdoored models from untrusted sources
Data leakage Sensitive data in prompts/training

๐ŸŽค Interview STAR Example

Situation: E-commerce app had no purchase limitsโ€”attackers exploited promo codes to get unlimited discounts.
Task: Redesign the promotion system with abuse prevention.
Action: Conducted threat modeling session with dev team. Identified 12 abuse cases. Implemented per-user promo limits, velocity checks (max 3 promos/hour), and fraud scoring. Added monitoring for unusual redemption patterns.
Result: Fraudulent promo abuse dropped by 94%. System flagged and blocked a bot attack within 5 minutes of launch.

๐Ÿ“š References