Threat Model

Threat model this system.

What it does and who uses it: [SYSTEM + USER TYPES INCLUDING ANONYMOUS ONES]
Architecture, data flows, and dependencies:
"""
[PASTE THE DESIGN, THE RELEVANT CODE, OR A DESCRIPTION OF COMPONENTS AND HOW DATA MOVES BETWEEN THEM]
"""
Data handled: [WHAT KINDS, INCLUDING PERSONAL, PAYMENT, HEALTH, OR CREDENTIALS]
Authentication and authorization today: [HOW IT WORKS]
Existing controls: [WAF, RATE LIMITS, ENCRYPTION, LOGGING, REVIEWS]
What would be worst for this business: [THE OUTCOME YOU MOST WANT TO AVOID]

Produce:

1. **Assets and trust boundaries.** What is worth attacking, and every point where data or control crosses from less trusted to more trusted. List the boundaries explicitly; almost every real vulnerability lives on one.

2. **Threats by STRIDE**, per component and boundary: spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege. For each threat, give:
   - The attack path in concrete steps, starting from what the attacker already has
   - Who could do it: anonymous internet, authenticated user, another tenant, insider, compromised dependency
   - What it gets them
   - Likelihood and impact, with the reasoning rather than just a rating
   - The mitigation, and whether it exists today, is partial, or is missing

3. **Ranked findings.** The top 5-8 by risk, ordered, each with the smallest change that meaningfully reduces it. Prefer controls that remove the class of bug over controls that catch instances of it.

4. **Multi-tenancy and authorization**, called out separately: for each object a user can reach, what enforces that they can only reach their own. Broken object-level authorization is the most common serious flaw in systems like this and is invisible in an architecture diagram.

5. **Detection.** For each top threat, what would appear in logs or metrics if it happened, and whether we would actually notice. An undetectable threat is worse than it looks on a risk rating.

6. **Assumptions and out of scope**, stated plainly, including what parts of the system this model did not examine.

Rules: base findings on the architecture I described. Where you need to know something to judge a threat, ask rather than assuming a control exists. Do not write generic advice; every finding must name a component and an attack path in this system.