Insecure Design

A04 Insecure Design is a new category in OWASP 2021. Unlike other categories that describe implementation flaws, insecure design means the security control was never built in the first place. You cannot patch your way out of insecure design — it requires re-architecting the feature. The question to ask: "If I assumed an attacker would use this feature, how would I design it differently?"

What Insecure Design Looks Like

• Predictable secrets — reset tokens derived from timestamps, user IDs, or sequential counters instead of cryptographic randomness
• No rate limiting on sensitive actions — login, OTP verification, and password reset endpoints have unlimited retries, allowing brute-force
• Business logic flaws — the application never validates that a business rule holds (e.g., negative quantities, applying a coupon multiple times, gift card abuse)
• Flat trust models — all authenticated users are treated identically regardless of context (IP, device, risk score)
• No abuse cases considered — the design process only modelled happy-path scenarios, never adversarial ones

Predictable Reset Token — Vulnerable Design

# VULNERABLE — reset token is user_id + "0000"; entirely predictable
import random

def generate_reset_token(user_id: int) -> str:
    return str(user_id) + "0000"   # attacker knows user_id=1 (admin) → token is "10000"

# Also broken: time-based tokens
def generate_reset_token_v2(user_id: int) -> str:
    return str(user_id) + str(int(time.time()))[-4:]   # predictable within a ~10-second window

No Rate Limiting — Vulnerable Design

# VULNERABLE — no attempt counter, no lockout, no delay
@app.post("/verify-otp")
def verify_otp(otp: str = Form()):
    if otp == admin_otp:           # 4 digits = 10,000 possibilities
        return {"flag": FLAG}      # attacker enumerates 0000–9999 in < 1 minute
    return {"error": "wrong otp"}

# Brute-force attack:
for i in range(10000):
    r = requests.post("/verify-otp", data={"otp": f"{i:04d}"})
    if "flag" in r.text:
        print(f"OTP: {i:04d}")
        break

Fixed Design

import secrets
from datetime import datetime, timedelta

# FIXED — cryptographically random token with expiry
def generate_reset_token(user_id: int) -> str:
    token = secrets.token_urlsafe(32)    # 256 bits of randomness; unguessable
    token_store[token] = {
        "user_id": user_id,
        "expires": datetime.utcnow() + timedelta(minutes=15)   # short expiry window
    }
    return token

# FIXED — rate limiting on OTP with lockout after 5 attempts
attempt_count = {}

@app.post("/verify-otp")
def verify_otp(request: Request, otp: str = Form()):
    ip = request.client.host
    attempts = attempt_count.get(ip, 0)
    if attempts >= 5:
        raise HTTPException(429, "Too many attempts. Try again in 15 minutes.")
    if otp != admin_otp:
        attempt_count[ip] = attempts + 1
        return {"error": "wrong otp"}
    attempt_count.pop(ip, None)
    return {"flag": FLAG}

Real-World Examples

• Instagram (2019) — Password reset via 6-digit SMS code had no rate limit; 1,000,000 requests/hour were possible. Account takeover at scale. Paid $30,000 bug bounty.
• PayPal (2012) — Password reset flow revealed whether an email was registered in the system, enabling account enumeration for targeted phishing
• Robinhood (2021) — 5 million email addresses and 2 million names exposed via a social-engineering attack on customer support — no design control to limit what support agents could export
• Any "security question" system — "What is your mother's maiden name?" can be answered from LinkedIn/Facebook; fundamentally insecure design regardless of implementation quality

How to Fix — Checklist

• Cryptographic randomness for all secrets — use secrets.token_urlsafe(32) (Python) or crypto.randomBytes(32) (Node). Never timestamps, IDs, or random
• Rate limiting on every authentication/verification endpoint — max 5 attempts, exponential backoff or IP lockout, CAPTCHA after threshold
• Short token expiry — password reset tokens expire in 15 minutes; OTPs expire in 30 seconds
• Threat modelling during design — use STRIDE or abuse cases: for every feature, ask "how would an attacker misuse this?"
• Single-use tokens — invalidate a reset/OTP token immediately after first use, even if still within the expiry window