Perform a threat model for the following feature or component:
$ARGUMENTS
What to do
Produce a developer-focused threat model. If no description was provided in the arguments, ask:
- What are you building? (feature name + description)
- What tech stack is involved?
- Do you have code snippets, data flows, or architecture notes to analyze?
Write threats in plain language — concrete attack scenarios a developer would understand, not abstract security categories. Every threat should link to specific evidence from the provided context.
Step 1 — Understand the Feature
Extract:
- Feature/component name — what is this?
- Description — what does it do, what problem does it solve?
- Tech stack — languages, frameworks, databases, cloud services
- Data touched — credentials, PII, payment data, tokens, internal config, etc.
- System boundaries — what calls this? what does it call? external vs. internal?
- Trust model — who are the actors? (users, admins, anonymous, third-party services)
Step 2 — Identify Attack Surfaces
Scan for:
- Authentication endpoints (login, registration, password reset, OAuth callbacks)
- File upload / download handlers
- External API integrations (third-party services, webhooks, callbacks)
- Admin / privileged operations
- Data exports or bulk operations
- Cross-tenant operations in multi-tenant systems
- Unauthenticated or public endpoints
- Async jobs or background workers that consume external data
And sensitive data patterns:
- Credentials and secrets (passwords, API keys, tokens, private keys)
- PII (names, emails, phone numbers, addresses, SSNs)
- Financial data (card numbers, account numbers, transaction history)
- Health data (PHI, medical records, diagnoses)
- Internal configuration or infrastructure details
Step 3 — Generate Threats
Consider these attack dimensions:
- Spoofing — Can an attacker impersonate a user, service, or system?
- Tampering — Can data be modified in transit or at rest without detection?
- Repudiation — Can users deny actions due to missing audit trails?
- Information Disclosure — Can sensitive data leak through errors, logs, or responses?
- Denial of Service — Can an attacker exhaust resources or disrupt availability?
- Elevation of Privilege — Can a low-privilege user gain higher access?
Technology-specific risks to consider:
- JWT: algorithm confusion (
alg: none), token theft, long-lived tokens, missing expiry checks
- OAuth: redirect URI manipulation, CSRF on callback, token leakage in logs/referrers
- File uploads: SSRF via URL fetch, path traversal, malicious file execution, unrestricted size
- SQL databases: injection via raw queries, excessive DB permissions, unencrypted sensitive columns
- Redis/caches: cache poisoning, unauthenticated access, insecure TTLs
- Webhooks: missing signature validation, replay attacks, SSRF via callback URLs
- S3/blob storage: public bucket misconfiguration, predictable key names, missing server-side encryption
- Microservices: missing service-to-service auth, internal SSRF, implicit trust between services
For each threat, provide:
- ID: TM-1, TM-2, ... (sequential)
- What can go wrong: Plain-language attack scenario — who does what, how, what they get
- Impact: Business consequence (account takeover, data breach, service disruption, etc.)
- Likelihood: high / medium / low — based on exploitability and attacker motivation
- Data affected: What data is at risk
- Mitigation: Specific fix — name the library, function, config option, or pattern to use
- Status: open (default unless user says otherwise)
- Evidence: What in the description/code/architecture justifies this threat
Step 4 — Output the Threat Model
Produce this structure:
Threat Model: [Feature/Component Name]
Author: security-review
Created: [today's date in YYYY-MM-DD]
What Are We Building?
[Description of the feature]
What Data Does It Touch?
- [Data item — be specific: "User passwords stored as bcrypt hashes in PostgreSQL users table"]
- [Data item]
Technologies
[Comma-separated list]
What Can Go Wrong?
TM-1: [Plain-language threat name]
- Impact: [Business impact — concrete consequence]
- Likelihood: [high | medium | low]
- Data Affected: [specific data types]
- Status: open
Mitigation: [Specific, actionable — name the algorithm, library, config flag, or code pattern]
Evidence: [What in the provided description/code makes this threat credible — quote or reference it]
TM-2: [Next threat]
...
Summary
[2–3 sentences: overall risk level, the most critical threats, what mitigations are highest priority]
Step 5 — Ask About Saving to File
After presenting the threat model, ask:
Would you like me to save this to threat-model.md?
If yes:
- Ask for the file path (default:
threat-model.md in the current directory)
- If a
threat-model.md already exists, ask: append (add below existing content) or replace?
- Write the threat model as a well-formatted markdown document matching the structure above
- If appending, separate from existing content with
---