┌──────────────────────────────────────────────────────────┐
│                  RELATIVE COST TO FIX                    │
├───────────────┬──────────────────────────────────────────┤
│ Requirements  │ 💰 x1                                    │
│ Design        │ 💰💰 x5                                  │
│ Development   │ 💰💰💰 x10                               │
│ Testing       │ 💰💰💰💰 x20                             │
│ Production    │ 💰💰💰💰💰💰💰💰💰💰 x100              │
└───────────────┴──────────────────────────────────────────┘

Source: IBM Systems Sciences Institute / NIST

Insecure Design = "We didn't think about that"
                 + "Who would even do that?"
                 + "We'll add security later"
                 + "That's an edge case, nobody will try it"

❌ Insecure Design is NOT:
   - A specific vulnerability like SQL Injection or XSS
   - A coding mistake
   - A misconfiguration
   - Something that can be caught by a SAST scanner

✅ Insecure Design IS:
   - A missing security control that was never planned
   - A flawed business logic that enables abuse
   - An architecture that trusts untrusted input by design
   - A system that fails open instead of failing secure
   - The absence of rate limiting, MFA, or abuse prevention
     because nobody thought to include them

✅ Perfect Implementation + Weak Design   = VULNERABLE SYSTEM (always)
🟡 Weak Implementation   + Strong Design  = FIXABLE SYSTEM (patch it)
✅ Perfect Implementation + Strong Design  = SECURE SYSTEM (the goal)

✅ Maximum 4 seats per session/user
✅ Reservation window: 5 minutes (not 15)
✅ No seat lock until payment process begins ("soft hold" only)
✅ CAPTCHA + device fingerprinting for all reservations
✅ Behavioral analysis: flag accounts making rapid bulk reservations
✅ Queue system for high-demand events
✅ Proof-of-work challenge for API consumers

🔴 INSECURE DESIGN:

Client sends:
POST /api/order
{
    "product_id": 1337,
    "quantity": 1,
    "price": 0.01,        ← The CLIENT dictates the price!
    "discount": 99,        ← The CLIENT dictates the discount!
    "currency": "USD"
}

Server blindly trusts and processes the order at $0.01

✅ SECURE DESIGN:

Client sends:
POST /api/order
{
    "product_id": 1337,
    "quantity": 1
    "text-slate-500 font-normal italic">// Price is NEVER accepted from the client
    "text-slate-500 font-normal italic">// Discount codes are validated server-side
}

Server-side logic:
1. Fetch product price from database
2. Validate discount code against server-side rules
3. Calculate total on the server
4. Verify calculated total matches expected range
5. Write audit log for every transaction
6. Flag transactions with unusual discount patterns

✅ Email-based recovery link with 15-minute expiry
✅ SMS/TOTP OTP with rate limiting (max 3 attempts)
✅ MFA challenge before allowing password reset
✅ Pre-generated account recovery codes (printed and stored safely)
✅ Identity verification through multiple independent factors
✅ Notify the user on ALL registered channels when a reset is requested

🔴 INSECURE DESIGN:

GET /api/users/1001/medical-records    ← User 1001's medical data

Attacker simply changes the ID:
GET /api/users/1002/medical-records    ← Someone else's medical data! 💀

✅ SECURE DESIGN:

1. Use UUIDs: GET /api/users/a8f3b2c1-4d5e.../medical-records
   → Eliminates enumeration

2. Resource-level authorization on EVERY request:
   → Token's user_id == requested resource's owner_id?
   → Does the user have the required role/permission?

3. Consistent authorization enforcement:
   → Centralized policy engine (OPA, Casbin, etc.)
   → Every endpoint goes through the same authz middleware

4. Return 404 (not 403) for unauthorized access:
   → Don't reveal that the resource exists

5. Comprehensive audit logging:
   → Log every access attempt (success AND failure)

🔴 INSECURE DESIGN — No abuse case was ever considered:

1. User applies coupon code "WELCOME50" (-50% discount)
2. User places order → pays $50 instead of $100
3. User cancels the order → gets full $50 refund
4. User applies the SAME coupon again → pays $50
5. Repeat infinitely

Worse:
6. User discovers coupon codes are sequential: WELCOME50, WELCOME51, WELCOME52...
7. User brute-forces valid coupon codes
8. User shares valid codes on public forums

✅ SECURE DESIGN:

1. Coupon usage tracked per-user in database (one-time use flag)
2. Coupon bound to specific user segment (new users only, etc.)
3. Refund does NOT automatically re-enable coupon — manual review required
4. Coupon codes use cryptographically random strings (not sequential)
5. Anomaly detection: flag accounts with excessive coupon usage
6. Coupon issuance rate limiting
7. Server-side validation of ALL coupon rules on every application

# 🔴 VULNERABLE — Stack trace and internal details exposed to user
@app.route('/login', methods=['POST'])
def login():
    try:
        user = db.execute(
            f"SELECT * FROM users WHERE email='{request.json['email']}'"
        )
        if not verify_password(request.json['password'], user.password_hash):
            return {
                "error": f"Wrong password for user {request.json['email']} "
                         f"in table 'users' (schema: public, db: prod_userdb)"
            }, 401  # ← Leaks table name, schema, database name
    except Exception as e:
        return {"error": str(e)}, 500
        # ← Leaks full stack trace, SQL errors, internal paths


# ✅ SECURE — Generic messages to user, detailed logs internally
@app.route('/login', methods=['POST'])
def login():
    try:
        user = authenticate(request.json.get('email'), request.json.get('password'))
        if not user:
            return {"error": "Invalid email or password"}, 401
            # ← Same message whether email exists or not (prevents enumeration)
    except Exception as e:
        error_id = str(uuid.uuid4())
        logger.error(f"Login error [{error_id}]: {e}", exc_info=True)
        # ← Full details go to internal logs only
        return {
            "error": "An unexpected error occurred",
            "reference": error_id
            # ← User gets a reference ID to report, not the actual error
        }, 500

// 🔴 VULNERABLE — Authorization enforced ONLY in JavaScript
function deleteUser(userId) {
    if (currentUser.role === 'admin') {  // ← Client-side check only
        fetch(`/api/users/${userId}`, { method: 'DELETE' });
    } else {
        alert('Access denied!');
    }
}

// Attacker opens DevTools, runs:
// fetch('/api/users/1002', { method: 'DELETE' })
// → Server happily deletes the user because it has NO authorization check

# ✅ SECURE — Authorization enforced on the SERVER
@app.route('/api/users/<user_id>', methods=['DELETE'])
@require_auth  # ← Authentication middleware
def delete_user(user_id):
    # Server-side authorization check
    if not current_user.has_permission('user:delete'):
        audit_log.warning(
            f"Unauthorized delete attempt by user {current_user.id} "
            f"for target {user_id}"
        )
        abort(403)  # ← Server says NO
    
    # Additional check: prevent self-deletion
    if user_id == current_user.id:
        abort(400, "Cannot delete your own account")
    
    # Proceed with deletion
    user = User.query.get_or_404(user_id)
    user.soft_delete()  # ← Soft delete, not hard delete (another design decision)
    db.session.commit()
    
    audit_log.info(f"User {user_id} deleted by admin {current_user.id}")
    return {"message": "User deleted"}, 200

Design Flaw: No rate limiting on OTP verification endpoint

🔴 VULNERABLE:
POST /api/verify-otp
{ "phone": "+1234567890", "otp": "1234" }

→ 4-digit OTP = only 10,000 possible combinations
→ No rate limiting = attacker tries all 10,000 in ~30 seconds
→ Account takeover guaranteed

✅ SECURE DESIGN:
1. 6-digit OTP (1,000,000 combinations)
2. Max 3 attempts per OTP
3. OTP expires after 5 minutes
4. 30-second cooldown between OTP requests
5. Account lockout after 5 failed OTPs in 1 hour
6. CAPTCHA after 2 failed attempts
7. Notify user of failed verification attempts

🔐 Principle: "Never trust, always verify"

For EVERY request, regardless of origin:
┌──────────────────────────────────────────────────────┐
│  1. Verify Identity    — WHO is making this request? │
│  2. Verify Device      — WHAT device are they using? │
│  3. Verify Context     — WHERE, WHEN, and WHY?       │
│  4. Enforce Least Privilege — Minimum permissions     │
│  5. Assume Breach      — Monitor and log everything   │
│  6. Verify Explicitly  — Don't trust cached authz     │
└──────────────────────────────────────────────────────┘

Traditional Security:  "Inside the firewall = trusted"      ❌
Zero Trust:            "Nothing is trusted, ever, period"    ✅

# ═══════════════════════════════════════════════════
# 🔴 FAIL OPEN — If auth service is down, allow everything
# ═══════════════════════════════════════════════════

def check_permission(user, resource):
    try:
        return authorization_service.check(user, resource)
    except ServiceUnavailableError:
        return True  # ← If auth service is down, GRANT ACCESS TO EVERYTHING 😱
        # "We can't let auth service downtime affect user experience!"


# ═══════════════════════════════════════════════════
# ✅ FAIL SECURE — If auth service is down, deny everything
# ═══════════════════════════════════════════════════

def check_permission(user, resource):
    try:
        return authorization_service.check(user, resource)
    except ServiceUnavailableError:
        logger.critical(
            "Authorization service is DOWN! "
            "All requests are being denied as a security precaution."
        )
        alert_ops_team(severity="P1")
        return False  # ← If auth service is down, DENY ALL ACCESS 🔒
        # "Security is more important than availability in this context"
    except Exception as e:
        logger.error(f"Unexpected authorization error: {e}")
        return False  # ← Default deny for ANY unexpected error

# ✅ Everything should be CLOSED/RESTRICTED by default
# Access is GRANTED explicitly, never implicitly

security:
  cors:
    allowed_origins: []              # Default: NO origins allowed
    allowed_methods: ["GET"]         # Default: read-only
  authentication:
    required: true                   # Default: auth REQUIRED
    mfa_enabled: true                # Default: MFA ON
    password_min_length: 12          # Default: 12 characters
    password_require_complexity: true
  session:
    timeout_minutes: 15              # Default: 15-minute timeout
    secure_cookie: true              # Default: HTTPS only
    same_site: "Strict"              # Default: strict SameSite
    http_only: true                  # Default: no JS access to cookies
  rate_limiting:
    enabled: true                    # Default: rate limiting ON
    requests_per_minute: 60          # Default: 60 req/min
    login_attempts_per_hour: 10      # Default: 10 login attempts/hour
  file_upload:
    enabled: false                   # Default: uploads DISABLED
    max_size_mb: 5                   # Default: 5MB max
    allowed_types: []                # Default: NO file types allowed
  logging:
    audit_trail: true                # Default: audit ON
    log_auth_events: true            # Default: log all auth events
  headers:
    x_content_type_options: "nosniff"
    x_frame_options: "DENY"
    strict_transport_security: "max-age=31536000; includeSubDomains"
    content_security_policy: "default-src 'self'"

🔐 Critical operations should require MULTIPLE actors:

Example: Financial Transfer > $10,000

Step 1: Initiator (Finance Analyst) creates the transfer request
Step 2: Reviewer (Finance Manager) approves the transfer
Step 3: System verifies both actors are different people
Step 4: System verifies both actors have the required roles
Step 5: Transfer is executed
Step 6: Both actors are notified of completion
Step 7: Audit trail records all actors, timestamps, and actions

❌ One person should NEVER be able to:
   - Create AND approve a transaction
   - Write code AND deploy it to production
   - Create a user AND assign admin privileges

🔴 "Nobody knows our API endpoint, so we don't need authentication"
🔴 "This port isn't commonly scanned, so we don't need to secure it"
🔴 "Our source code is proprietary, so nobody can find the vulnerabilities"
🔴 "We use a custom encryption algorithm that nobody knows about"

✅ Kerckhoffs' Principle (1883):
   "A cryptographic system should be secure even if everything about 
    the system, except the key, is public knowledge."

   Applied broadly: Your system should be secure even if the attacker 
   has your source code, knows your architecture, and understands 
   every design decision you made.

🔴 Storing price in a hidden HTML field
🔴 Performing authorization checks in JavaScript only
🔴 Relying on client-side input validation without server-side validation
🔴 Using a "disabled" button as a security control (DevTools → enable → click)
🔴 Sending user role in a cookie or local storage and trusting it
🔴 Using client-side feature flags for security-sensitive features

✅ THE GOLDEN RULE:
   "All input from the client is HOSTILE until proven otherwise."
   
   The client (browser, mobile app, API consumer) is ALWAYS under
   the attacker's control. EVERY input, header, cookie, and parameter
   must be validated, sanitized, and authorized on the SERVER.

🔴 WRONG: A single "isAdmin" boolean controls everything

if (user.isAdmin) {
    "text-slate-500 font-normal italic">// Can do LITERALLY ANYTHING:
    "text-slate-500 font-normal italic">// - Delete all users
    "text-slate-500 font-normal italic">// - Access financial records
    "text-slate-500 font-normal italic">// - Modify system configuration
    "text-slate-500 font-normal italic">// - Export all data
    "text-slate-500 font-normal italic">// - Impersonate other users
}

✅ CORRECT: Granular, resource-level permission system

Permission Matrix:
┌──────────────────────┬──────┬───────┬────────┬──────────┬───────────┐
│ Resource             │ Read │ Write │ Delete │ Export   │ Admin     │
├──────────────────────┼──────┼───────┼────────┼──────────┼───────────┤
│ Own Profile          │  ✅  │  ✅   │  ❌   │  ✅      │  ❌      │
│ Team Members         │  ✅  │  ❌   │  ❌   │  ❌      │  ❌      │
│ Department Data      │  ✅  │  ✅   │  ❌   │  ❌      │  ❌      │
│ Financial Reports    │  ❌  │  ❌   │  ❌   │  ❌      │  ❌      │
│ System Configuration │  ❌  │  ❌   │  ❌   │  ❌      │  ❌      │
│ Audit Logs           │  ❌  │  ❌   │  ❌   │  ❌      │  ❌      │
└──────────────────────┴──────┴───────┴────────┴──────────┴───────────┘

The Real Timeline:

Sprint 1:  "Let's build the feature first, we'll add auth later"
Sprint 2:  "We're behind schedule, security will have to wait"
Sprint 3:  "The feature works, let's ship it"
Sprint 4:  "We have new features to build, security can wait"
Sprint 5:  "We have too much tech debt to refactor for security now"
Sprint 47: "We got breached"
Sprint 48: "Why didn't we add security earlier?"

Cost to add security in Sprint 1:    💰
Cost to add security in Sprint 48:   💰💰💰💰💰💰💰💰💰💰

If Layer 0 fails: → Attacker bypasses DNS/CDN protections
   But Layer 1 (WAF) blocks malicious requests ✅

If Layer 1 fails: → Malicious traffic reaches your network
   But Layer 2 (segmentation) limits blast radius ✅

If Layer 2 fails: → Attacker moves laterally in the network
   But Layer 3 (identity) requires strong authentication ✅

If Layer 3 fails: → Attacker authenticates somehow
   But Layer 4 (application) validates all input and enforces authz ✅

If Layer 4 fails: → Attacker exploits an application vulnerability
   But Layer 5 (data) keeps data encrypted and tokenized ✅

If Layer 5 fails: → Attacker accesses raw data
   But Layer 6 (monitoring) detects the breach in real-time ✅

Every layer must fail INDEPENDENTLY for a full compromise.

Security Requirements Gathering:

□ Functional security requirements defined?
  → "Users MUST authenticate with MFA before accessing financial data"
  
□ Abuse cases / misuse cases written?
  → "An attacker WILL attempt to brute-force the login endpoint"
  → "A malicious user WILL try to access other users' data"
  → "An insider WILL attempt to exfiltrate customer data"
  
□ Compliance requirements mapped?
  → GDPR (data privacy), PCI-DSS (payment), HIPAA (health), SOC 2
  
□ Data classification completed?
  → Public | Internal | Confidential | Restricted
  
□ Security SLAs defined?
  → "Critical vulnerabilities must be patched within 24 hours"
  → "99.9% uptime with DDoS protection"
  
□ Privacy requirements specified?
  → Data retention periods, right to deletion, consent management

Secure Design Activities:

□ Threat Modeling conducted? (STRIDE / PASTA / LINDDUN)
□ Attack surface analysis performed?
□ Security architecture review completed by security team?
□ Trust boundaries clearly identified and documented?
□ Secure design patterns applied?
□ Failure modes analyzed? (Fail secure, not fail open)
□ Authentication & authorization architecture designed?
□ Data flow diagrams created with security annotations?
□ Third-party integration risks assessed?
□ Cryptographic choices documented and justified?

Secure Development Practices:

□ Secure coding standards adopted and enforced?
□ SAST tools integrated into CI/CD pipeline?
□ Pre-commit hooks for secret detection? (git-secrets, detect-secrets)
□ Dependency scanning active? (Snyk, Dependabot)
□ Security-focused code reviews conducted?
□ Secret management solved? (HashiCorp Vault, AWS Secrets Manager)
□ Parameterized queries / ORM used? (No string concatenation for SQL)
□ Output encoding applied in all templates?
□ Security unit tests written for auth/authz logic?

Security Testing Activities:

□ DAST scan completed?
□ Penetration testing performed by qualified testers?
□ Business logic testing done? (abuse cases from Phase 1)
□ Authentication bypass testing?
□ Authorization bypass testing? (horizontal & vertical)
□ Race condition testing? (TOCTOU flaws)
□ Fuzz testing for input parsing?
□ API security testing? (OWASP API Security Top 10)
□ Session management testing?
□ Error handling and information leakage testing?

# ══════════════════════════════════════════════════════════════
# 🔴 INSECURE DESIGN — No rate limiting, no validation, no defense
# ══════════════════════════════════════════════════════════════

@app.route('/api/register', methods=['POST'])
def register():
    email = request.json.get('email')
    password = request.json.get('password')
    
    # No rate limiting — a bot can create 100,000 accounts per hour
    # No CAPTCHA — automated registration is trivial
    # No email verification — fake emails accepted
    # No password policy — "1" is a valid password
    # No duplicate check timing safety — email enumeration possible
    
    user = User(email=email, password=hash_password(password))
    db.session.add(user)
    db.session.commit()
    
    return {"message": "Registered successfully"}, 201


# ══════════════════════════════════════════════════════════════
# ✅ SECURE DESIGN — Defense in depth at every step
# ══════════════════════════════════════════════════════════════

from flask_limiter import Limiter
from flask_limiter.util import get_remote_address
import re
import uuid
import bcrypt
import secrets
from datetime import datetime, timedelta

limiter = Limiter(app, key_func=get_remote_address)

# Design Decisions documented:
# 1. IP-based rate limiting (5 registrations per hour per IP)
# 2. CAPTCHA verification before processing
# 3. Strict email format validation (server-side)
# 4. Strong password policy (12+ chars, complexity, breach check)
# 5. Timing-safe duplicate check (prevent email enumeration)
# 6. Email verification required before account activation
# 7. Comprehensive audit logging
# 8. No sensitive data in responses

@app.route('/api/register', methods=['POST'])
@limiter.limit("5 per hour")  # Design: max 5 registrations per IP per hour
def register():
    data = request.json or {}
    
    # ── Step 1: CAPTCHA Verification ──
    captcha_token = data.get('captcha_token')
    if not captcha_token or not verify_captcha(captcha_token):
        audit_log.warning(f"Failed CAPTCHA from {request.remote_addr}")
        return {"error": "CAPTCHA verification failed"}, 400
    
    # ── Step 2: Input Validation (Server-Side, Whitelist) ──
    email = data.get('email', '').strip().lower()
    password = data.get('password', '')
    
    if not email or not re.match(
        r'^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$', email
    ):
        return {"error": "Invalid email format"}, 400
    
    if len(email) > 254:  # RFC 5321 max email length
        return {"error": "Email address too long"}, 400
    
    # ── Step 3: Password Policy Enforcement ──
    password_errors = validate_password_strength(password)
    if password_errors:
        return {"error": "Password does not meet requirements",
                "details": password_errors}, 400
    
    # ── Step 4: Breached Password Check (HaveIBeenPwned API) ──
    if is_password_breached(password):
        return {
            "error": "This password has been found in known data breaches. "
                     "Please choose a different password."
        }, 400
    
    # ── Step 5: Timing-Safe Duplicate Check ──
    # Always take the same amount of time regardless of whether
    # the email exists — prevents email enumeration attacks
    processing_start = datetime.utcnow()
    
    existing_user = User.query.filter_by(email=email).first()
    
    # Ensure consistent response time (200-300ms)
    elapsed = (datetime.utcnow() - processing_start).total_seconds()
    if elapsed < 0.25:
        time.sleep(0.25 - elapsed)
    
    if existing_user:
        # SAME response as success — attacker can't tell if email exists
        return {
            "message": "If this email is not already registered, "
                       "you will receive a verification email shortly."
        }, 200
    
    # ── Step 6: Create Unverified User ──
    verification_token = secrets.token_urlsafe(32)
    
    user = User(
        id=str(uuid.uuid4()),  # UUID, not sequential integer
        email=email,
        password_hash=bcrypt.hashpw(
            password.encode(), bcrypt.gensalt(rounds=12)
        ).decode(),
        is_verified=False,
        verification_token=verification_token,
        verification_expires=datetime.utcnow() + timedelta(hours=24),
        created_ip=anonymize_ip(request.remote_addr),  # Store anonymized IP
        created_at=datetime.utcnow()
    )
    db.session.add(user)
    db.session.commit()
    
    # ── Step 7: Send Verification Email ──
    send_verification_email(
        to=email,
        token=verification_token,
        expires_in="24 hours"
    )
    
    # ── Step 8: Audit Log ──
    audit_log.info(
        f"Registration attempt | "
        f"email_prefix={email[:3]}*** | "
        f"ip={anonymize_ip(request.remote_addr)} | "
        f"user_agent={request.headers.get('User-Agent', 'unknown')[:50]}"
    )
    
    # ── Step 9: Same response regardless of outcome ──
    return {
        "message": "If this email is not already registered, "
                   "you will receive a verification email shortly."
    }, 200


def validate_password_strength(password: str) -> list:
    """Design Decision: Password policy enforcement"""
    errors = []
    if len(password) < 12:
        errors.append("Password must be at least 12 characters long")
    if len(password) > 128:
        errors.append("Password must not exceed 128 characters")
    if not re.search(r'[A-Z]', password):
        errors.append("Password must contain at least one uppercase letter")
    if not re.search(r'[a-z]', password):
        errors.append("Password must contain at least one lowercase letter")
    if not re.search(r'\d', password):
        errors.append("Password must contain at least one digit")
    if not re.search(r'[!@#$%^&*(),.?":{}|<>\-_=+\[\]\\;\'`~]', password):
        errors.append("Password must contain at least one special character")
    if re.search(r'(.)\1{2,}', password):
        errors.append("Password must not contain 3 or more repeated characters")
    return errors

# ══════════════════════════════════════════════════════════════
# 🔴 INSECURE DESIGN — Trusts everything from the client
# ══════════════════════════════════════════════════════════════

@app.route('/upload', methods=['POST'])
def upload():
    file = request.files['file']
    # Saves directly to web root with original filename
    # No size check, no type check, no malware scan
    # Path traversal possible: filename="../../etc/cron.d/backdoor"
    file.save(f'/var/www/html/uploads/{file.filename}')
    return {"url": f"https://example.com/uploads/{file.filename}"}


# ══════════════════════════════════════════════════════════════
# ✅ SECURE DESIGN — Defense at every step
# ══════════════════════════════════════════════════════════════

import uuid
import magic  # python-magic for MIME detection via magic bytes
from pathlib import Path
from werkzeug.utils import secure_filename

# Design Decisions:
ALLOWED_EXTENSIONS = {'.jpg', '.jpeg', '.png', '.gif', '.pdf'}
ALLOWED_MIMES = {
    'image/jpeg', 'image/png', 'image/gif', 'application/pdf'
}
MAX_FILE_SIZE = 5 * 1024 * 1024  # 5MB
UPLOAD_DIR = Path('/var/data/uploads')  # OUTSIDE web root
QUARANTINE_DIR = Path('/var/data/quarantine')

@app.route('/api/files', methods=['POST'])
@require_auth
@limiter.limit("10 per hour")
def upload_file():
    # ── Step 1: Check if file exists in request ──
    file = request.files.get('file')
    if not file or not file.filename:
        return {"error": "No file provided"}, 400
    
    # ── Step 2: File size check (before reading entire file) ──
    file.seek(0, 2)  # Seek to end
    file_size = file.tell()
    file.seek(0)     # Seek back to beginning
    
    if file_size == 0:
        return {"error": "Empty file"}, 400
    if file_size > MAX_FILE_SIZE:
        return {
            "error": f"File too large. Maximum size: "
                     f"{MAX_FILE_SIZE // 1024 // 1024}MB"
        }, 400
    
    # ── Step 3: Extension whitelist check ──
    original_filename = secure_filename(file.filename)
    extension = Path(original_filename).suffix.lower()
    
    if extension not in ALLOWED_EXTENSIONS:
        audit_log.warning(
            f"Blocked file upload: extension '{extension}' "
            f"from user {current_user.id}"
        )
        return {"error": "File type not allowed"}, 400
    
    # ── Step 4: MIME type verification (magic bytes, not Content-Type header) ──
    header_bytes = file.read(2048)
    file.seek(0)
    detected_mime = magic.from_buffer(header_bytes, mime=True)
    
    if detected_mime not in ALLOWED_MIMES:
        audit_log.warning(
            f"MIME mismatch: claimed extension '{extension}', "
            f"detected MIME '{detected_mime}' "
            f"from user {current_user.id}"
        )
        return {"error": "File content does not match its extension"}, 400
    
    # ── Step 5: Generate safe filename (UUID-based) ──
    safe_filename = f"{uuid.uuid4().hex}{extension}"
    quarantine_path = QUARANTINE_DIR / safe_filename
    
    # ── Step 6: Save to quarantine first ──
    file.save(str(quarantine_path))
    
    # ── Step 7: Malware scan (ClamAV) ──
    if not scan_for_malware(quarantine_path):
        audit_log.critical(
            f"MALWARE DETECTED in upload from user {current_user.id} | "
            f"original_name: {original_filename}"
        )
        quarantine_path.unlink()  # Delete infected file
        alert_security_team(
            event="malware_upload",
            user_id=current_user.id,
            filename=original_filename
        )
        return {"error": "File rejected by security scan"}, 400
    
    # ── Step 8: Strip metadata (EXIF data can contain GPS, device info) ──
    strip_metadata(quarantine_path)
    
    # ── Step 9: Move from quarantine to permanent storage ──
    final_path = UPLOAD_DIR / safe_filename
    quarantine_path.rename(final_path)
    
    # ── Step 10: Re-encode images (neutralize image-based attacks) ──
    if detected_mime.startswith('image/'):
        reencode_image(final_path)
    
    # ── Step 11: Database record ──
    upload_record = FileUpload(
        id=str(uuid.uuid4()),
        user_id=current_user.id,
        original_name=original_filename[:255],
        stored_name=safe_filename,
        mime_type=detected_mime,
        size_bytes=file_size,
        sha256_hash=compute_sha256(final_path),
        uploaded_at=datetime.utcnow(),
        ip_address=anonymize_ip(request.remote_addr)
    )
    db.session.add(upload_record)
    db.session.commit()
    
    # ── Step 12: Audit log ──
    audit_log.info(
        f"File uploaded | id={upload_record.id} | "
        f"user={current_user.id} | "
        f"size={file_size} | mime={detected_mime}"
    )
    
    # ── Step 13: Return file access URL (via API, not direct path) ──
    return {
        "id": upload_record.id,
        "url": f"/api/files/{upload_record.id}",
        # ← Never expose the actual file path!
        # File is served through the API with authorization checks
        "size": file_size,
        "type": detected_mime
    }, 201

# ══════════════════════════════════════════════════════════════
# 🔴 INSECURE DESIGN — No authorization, IDOR vulnerability
# ══════════════════════════════════════════════════════════════

@app.route('/api/invoices/<invoice_id>')
def get_invoice(invoice_id):
    # No authentication check
    # No authorization check
    # Sequential IDs allow enumeration
    invoice = Invoice.query.get(invoice_id)
    return jsonify(invoice.to_dict())
    # Attacker: GET /api/invoices/1, 2, 3, 4... → dumps all invoices


# ══════════════════════════════════════════════════════════════
# ✅ SECURE DESIGN — Multi-layered authorization
# ══════════════════════════════════════════════════════════════

@app.route('/api/invoices/<invoice_id>')
@require_auth  # Layer 1: Authentication
@require_permission('invoice:read')  # Layer 2: Role-based permission
def get_invoice(invoice_id):
    # ── Layer 3: Input validation ──
    if not is_valid_uuid(invoice_id):
        return {"error": "Invalid invoice ID format"}, 400
    
    # ── Layer 4: Fetch resource ──
    invoice = Invoice.query.get(invoice_id)
    if not invoice:
        return {"error": "Invoice not found"}, 404
    
    # ── Layer 5: Resource-level authorization ──
    if not can_access_invoice(current_user, invoice):
        # Log the unauthorized access attempt with full context
        audit_log.warning(
            f"UNAUTHORIZED ACCESS ATTEMPT | "
            f"user={current_user.id} (role={current_user.role}) | "
            f"attempted_resource=invoice:{invoice_id} | "
            f"resource_owner={invoice.owner_id} | "
            f"ip={request.remote_addr}"
        )
        
        # Design Decision: Return 404, not 403
        # Returning 403 confirms the resource EXISTS
        # Returning 404 reveals nothing about resource existence
        return {"error": "Invoice not found"}, 404
    
    # ── Layer 6: Data filtering based on user's role ──
    # Different users see different fields
    response_data = invoice.to_filtered_dict(
        requesting_user=current_user,
        fields_policy=get_field_policy(current_user.role)
    )
    
    # ── Layer 7: Audit log (successful access) ──
    audit_log.info(
        f"Invoice accessed | invoice={invoice_id} | "
        f"user={current_user.id} | role={current_user.role}"
    )
    
    return jsonify(response_data), 200


def can_access_invoice(user, invoice) -> bool:
    """
    Resource-level authorization policy.
    
    Design Decision: Authorization rules are centralized here,
    not scattered across multiple endpoints.
    """
    # Rule 1: Owner can always access their own invoices
    if invoice.owner_id == user.id:
        return True
    
    # Rule 2: Finance managers can access invoices in their department
    if (user.has_role('finance_manager') 
            and invoice.department_id == user.department_id):
        return True
    
    # Rule 3: C-level executives can access all invoices (with logging)
    if user.has_role('executive'):
        audit_log.info(
            f"Executive access | user={user.id} | invoice={invoice.id}"
        )
        return True
    
    # Rule 4: External auditors can access invoices in their audit scope
    if (user.has_role('external_auditor') 
            and invoice.id in get_audit_scope(user.id)):
        return True
    
    # Default: DENY (fail secure)
    return False

📚 Essential Resources:
├── OWASP Resources
│   ├── OWASP Top 10 (2021)
│   ├── OWASP ASVS v4.0 (Application Security Verification Standard)
│   ├── OWASP Testing Guide v4.2
│   ├── OWASP API Security Top 10
│   ├── OWASP Cheat Sheet Series
│   │   ├── Authentication Cheat Sheet
│   │   ├── Authorization Cheat Sheet
│   │   ├── Session Management Cheat Sheet
│   │   ├── Input Validation Cheat Sheet
│   │   ├── Cryptographic Storage Cheat Sheet
│   │   ├── Error Handling Cheat Sheet
│   │   └── Threat Modeling Cheat Sheet
│   └── OWASP Secure Coding Practices Quick Reference
│
├── Books
│   ├── "Threat Modeling: Designing for Security" — Adam Shostack
│   ├── "The Web Application Hacker's Handbook" — Stuttard & Pinto
│   ├── "Secure by Design" — Dan Bergh Johnsson et al.
│   ├── "Building Secure and Reliable Systems" — Google SRE
│   └── "Security Engineering" — Ross Anderson
│
├── Standards & Frameworks
│   ├── NIST SP 800-53 (Security Controls)
│   ├── NIST SP 800-160 (Systems Security Engineering)
│   ├── ISO 27001/27002 (Information Security Management)
│   ├── CWE/SANS Top 25 Most Dangerous Software Weaknesses
│   └── MITRE ATT&CK Framework
│
└── Training & Practice
    ├── OWASP WebGoat (Hands-on vulnerable app)
    ├── OWASP Juice Shop (Modern vulnerable app)
    ├── PortSwigger Web Security Academy (Free)
    ├── HackTheBox / TryHackMe (Practice environments)
    └── Secure Code Warrior (Gamified secure coding)

┌─────────────────────────────────────────────────────────────┐
│                                                             │
│  1. 🤔 "How will an ATTACKER abuse this feature?"           │
│     → Write abuse cases. Think adversarially.               │
│                                                             │
│  2. 🤔 "What happens when this feature FAILS or ERRORS?"    │
│     → Design for failure. Fail secure, not open.            │
│                                                             │
│  3. 🤔 "What is the MINIMUM permission needed for this?"    │
│     → Apply least privilege. Default deny.                  │
│                                                             │
│  The moment you start asking these questions consistently,  │
│  you are thinking SECURE BY DESIGN. 🎯                      │
│                                                             │
└─────────────────────────────────────────────────────────────┘

┌────────────────────────────────────────────────────────────────────┐
│                        BREACH COST BREAKDOWN                       │
├────────────────────────────────────────────────────────────────────┤
│                                                                    │
│  Average cost of a data breach (2024):           $4.88 MILLION    │
│  Average cost if secure design was applied:      $0.15 MILLION    │
│                                                                    │
│  Time to identify a breach (avg):                194 DAYS          │
│  Time to contain a breach (avg):                 64 DAYS           │
│                                                                    │
│  Breaches caused by design flaws:                ~40%              │
│  Breaches preventable by threat modeling:        ~60%              │
│                                                                    │
│  Sources: IBM Cost of a Data Breach Report 2024, Ponemon Institute │
└────────────────────────────────────────────────────────────────────┘