sawrus/threat-modeling

Skill: Threat Modeling

Expertise: STRIDE framework, IDOR prevention, authorization boundary analysis, threat matrices for API and system security reviews.

When to load

When designing a new system, adding an integration, reviewing an architecture, or preparing for a security review.

STRIDE Framework

| Threat | Question | Example | |:---|:---|:---| | Spoofing | Can an attacker impersonate a user/service? | Forged JWT, SSRF to metadata service | | Tampering | Can data be modified in transit/at rest? | SQL injection, cache poisoning | | Repudiation | Can users deny performing an action? | Missing audit logs | | Information Disclosure | Can sensitive data be exposed? | Error messages leaking stack traces | | Denial of Service | Can the service be made unavailable? | No rate limiting on public endpoints | | Elevation of Privilege | Can a low-privilege user gain higher access? | IDOR, broken object-level authorization |

Threat Modeling Workflow

1. Identify assets — list sensitive data, APIs, and trust boundaries in the system
2. Apply STRIDE — walk through each threat category against every asset and boundary
3. Score risks — rank by likelihood × impact (Critical / High / Medium / Low)
4. Prioritize mitigations — address Critical/High first; document accepted risks for Medium/Low
5. Validate — verify mitigations with code review, SAST/DAST scans, or penetration testing

IDOR — Most Common API Vulnerability

# ❌ Vulnerable
@app.get("/invoices/{invoice_id}")
def get_invoice(invoice_id: int, current_user: User = Depends(get_current_user)):
    return db.query(Invoice).filter(Invoice.id == invoice_id).first()

# ✅ Safe: always scope to authenticated user
@app.get("/invoices/{invoice_id}")
def get_invoice(invoice_id: int, current_user: User = Depends(get_current_user)):
    invoice = db.query(Invoice).filter(
        Invoice.id == invoice_id,
        Invoice.owner_id == current_user.id  # ← ownership check
    ).first()
    if not invoice:
        raise HTTPException(status_code=404)  # 404, not 403
    return invoice

Common Mistakes

• Returning 403 instead of 404 — reveals that the resource exists, enabling enumeration
• Client-side authorization only — always enforce ownership and role checks server-side
• Missing audit logs for sensitive actions — makes repudiation threats undetectable
• Trusting internal service-to-service calls — apply zero-trust; validate JWTs at every boundary