| name | threat-modeling |
| description | Apply STRIDE with DFD trust boundaries and DREAD scoring. Use when implementing auth, file uploads, payments, webhooks, OAuth/SSO, APIs, multi-tenant, or external integrations — or when asked for a security review, audit, hardening, or vulnerability assessment. Triggers on: "is this secure", "security review", "make this secure", "harden this", "threat model", "STRIDE", "trust boundary". Use for ANY feature that handles user data, accepts external input, or crosses trust boundaries.
|
Threat Modeling (STRIDE)
MANDATORY FIRST STEP
HARD GATE - Task Planning:
→ Threat modeling begins → Has TodoWrite created structured tasks covering all phases below?
No → STOP. Create tasks before any analysis.
Yes → Proceed.
TodoWrite: create one item per phase (minimum 5 items, one per STRIDE phase). Add more items only if the feature has >3 entry points OR >2 trust boundaries. Do NOT pad to 28 for a simple webhook / single-endpoint feature.
Phase 1: Data Flow Diagram & Trust Boundaries
Before enumerating threats, map the system. Skip this and you will miss threats.
- Identify all trust boundaries (network, process, data store, service, account)
- Build a DFD: external entities, processes, data stores, data flows (label protocol), trust boundary lines
- Map entry/exit points with trust levels (untrusted, semi-trusted, trusted)
Phase 2: STRIDE Threat Enumeration
Apply each category to every trust boundary crossing identified in Phase 1. For each category, ask the questions below and document threats found.
S - Spoofing Identity
Credential stuffing/brute force | Session hijacking (XSS, fixation) | API key extraction from client/logs | Webhook sender impersonation | Service-to-service spoofing (no mTLS) | OAuth token forgery/replay | DNS/IP spoofing (SSRF) | SMS/email verification bypass
T - Tampering with Data
Request body modification (no TLS/integrity) | Mass assignment/hidden fields | SQL injection | File overwrite (TOCTOU, path traversal) | JWT algorithm confusion (alg:none) | Queue payload alteration | Config/env injection | Audit log tampering
R - Repudiation
Missing auth event logging | No data modification audit trail | No immutable financial records | Log injection | Logs not tamper-evident | Insufficient forensic context
I - Information Disclosure
Verbose error messages | API over-fetching | Source maps/directory listing | PII in logs | Timing attacks (user enumeration) | No encryption at rest | SSRF to metadata endpoints | Secrets in code/env
D - Denial of Service
Missing rate limits | Unbounded payloads (zip bombs) | Expensive queries (ReDoS, N+1) | Noisy neighbor | Queue flooding | No circuit breakers | Account lockout weaponization | No graceful degradation
E - Elevation of Privilege
Missing server-side authz | IDOR via ID manipulation | Missing role checks on admin endpoints | Deserialization/SSTI RCE | Unrestricted file upload (web shell) | Known CVEs in dependencies | Container escape | OAuth scope escalation
Phase 3: Risk Scoring (DREAD)
Score each threat: Damage, Reproducibility, Exploitability, Affected users, Discoverability (each 1-3). Total = sum (range 5-15).
| Score | Priority | Action |
|---|
| 12-15 | Critical | Block release. Fix immediately. |
| 8-11 | High | Fix before release. Requires control. |
| 5-7 | Medium | Track. Fix in next sprint. Accept with documented rationale. |
When in doubt, score higher. If most threats score the same, you're not differentiating enough.
Feature Templates
Authentication / Login
Assets: Credentials, session tokens, reset tokens, MFA secrets
Entry points: Login, signup, password reset, MFA enrollment
Key trust boundaries: Browser-to-API, API-to-identity-provider, API-to-database
| Priority Threats | STRIDE | DREAD Focus |
|---|
| Credential stuffing / brute force | S | Reproducibility: high |
| Session fixation / hijacking | S, E | Exploitability: varies by cookie config |
| Password reset token leakage | I | Discoverability: check referrer headers |
| Account lockout weaponization | D | Affected users: targeted |
| MFA bypass via backup codes | S, E | Exploitability: social engineering |
File Upload
Assets: Stored files, file metadata, server filesystem
Entry points: Upload endpoint, download/preview endpoint
Key trust boundaries: Browser-to-API, API-to-storage, storage-to-CDN
| Priority Threats | STRIDE | DREAD Focus |
|---|
| Web shell upload / RCE | E | Damage: 3, Exploitability: 2-3 |
| Path traversal (write to arbitrary path) | T | Reproducibility: high if unsanitized |
| Zip bomb / decompression bomb | D | Affected users: all (server crash) |
| Access control bypass on downloads | I, E | Discoverability: IDOR on file IDs |
| Malware distribution via stored files | T | Affected users: downstream consumers |
Payment / Billing Flow
Assets: Payment credentials, transaction records, subscription state, invoices
Entry points: Checkout, webhook from payment provider, billing portal
Key trust boundaries: Browser-to-API, API-to-payment-provider, webhook-ingress
| Priority Threats | STRIDE | DREAD Focus |
|---|
| Price/quantity tampering in checkout request | T | Damage: 3 (financial loss) |
| Webhook signature bypass (replay/forge) | S | Reproducibility: high if no verification |
| Race condition on coupon/credit application | T, E | Exploitability: moderate |
| PCI data in logs or error messages | I | Discoverability: log search |
| Subscription state manipulation (skip billing) | T, E | Damage: ongoing revenue loss |
Webhook Integration
Assets: Webhook secrets, payload data, processing state
Entry points: Webhook receiver endpoint
Key trust boundaries: External-service-to-API, API-to-internal-queue
| Priority Threats | STRIDE | DREAD Focus |
|---|
| Missing signature verification | S | Exploitability: 3 (trivial to forge) |
| Replay attacks (no timestamp/nonce check) | S, T | Reproducibility: 3 |
| SSRF via URL fields in webhook payload | E, I | Damage: cloud metadata access |
| Queue flooding via rapid webhook delivery | D | Affected users: all |
| Idempotency failure (double-processing) | T | Damage: duplicate charges/actions |
OAuth / SSO
Assets: OAuth tokens, client secrets, user profile data, session state
Entry points: Authorization redirect, callback endpoint, token exchange
Key trust boundaries: Browser-to-IdP, IdP-to-API, API-to-resource-server
| Priority Threats | STRIDE | DREAD Focus |
|---|
| Open redirect via callback URL manipulation | S, I | Exploitability: 2-3 |
| CSRF on authorization flow (missing state param) | S | Reproducibility: 3 |
| Token leakage via referrer header or logs | I | Discoverability: 2 |
| Scope escalation / insufficient scope validation | E | Damage: broader access than consented |
| IdP impersonation (no issuer validation) | S | Damage: full account takeover |
CI/CD Pipeline
Assets: Source code, secrets/credentials, build artifacts, deployment keys
Entry points: Git push, PR events, artifact registry, deployment triggers
Key trust boundaries: Developer-to-VCS, VCS-to-CI, CI-to-artifact-store, CI-to-production
| Priority Threats | STRIDE | DREAD Focus |
|---|
| Secret exfiltration via build logs or env vars | I | Damage: 3 (all secrets compromised) |
| Malicious PR injecting code into build pipeline | T, E | Exploitability: depends on review policy |
| Dependency confusion / typosquatting | T | Discoverability: automated scanners exist |
| Build artifact tampering (unsigned artifacts) | T | Reproducibility: if registry is writable |
| Overprivileged CI service account | E | Damage: production access from CI |
API Gateway / Public API
Assets: API keys, rate limit state, routing configuration, backend services
Entry points: All public API endpoints
Key trust boundaries: Internet-to-gateway, gateway-to-backend-services
| Priority Threats | STRIDE | DREAD Focus |
|---|
| API key leakage in client apps or URLs | I | Discoverability: 3 (public code search) |
| Broken Object Level Authorization (BOLA) | E | Affected users: any user's data |
| Mass assignment via unvalidated fields | T | Exploitability: depends on framework |
| Rate limit bypass via header/IP rotation | D | Reproducibility: moderate |
| GraphQL introspection / query depth abuse | I, D | Exploitability: 2-3 |
WebSocket Connections
Assets: Real-time data streams, connection state, user presence
Entry points: WebSocket upgrade endpoint, message handlers
Key trust boundaries: Browser-to-WS-server, WS-server-to-backend
| Priority Threats | STRIDE | DREAD Focus |
|---|
| Missing authentication on WS upgrade | S, E | Exploitability: 3 |
| Cross-site WebSocket hijacking (CSWSH) | S | Reproducibility: 3 if no origin check |
| Message injection / channel subscription abuse | T, E | Damage: data corruption or leakage |
| Connection flooding (exhausting server resources) | D | Affected users: all connected users |
| Missing per-message authorization checks | E | Damage: access to unauthorized channels |
Multi-Tenant System
Assets: Tenant data, tenant configurations, shared infrastructure, API keys per tenant
Entry points: All endpoints with tenant context, admin/management APIs
Key trust boundaries: Tenant-A-to-tenant-B (logical), API-to-shared-database, tenant-admin-to-platform-admin
| Priority Threats | STRIDE | DREAD Focus |
|---|
| Cross-tenant data leakage via shared queries | I | Affected users: 3 (other tenants' data) |
| Tenant ID manipulation in requests | S, E | Exploitability: 2-3 (predictable IDs) |
| Noisy neighbor resource exhaustion | D | Affected users: all tenants on shared infra |
| Shared cache key collision between tenants | I, T | Discoverability: race conditions |
| Privilege escalation from tenant admin to platform admin | E | Damage: 3 (full platform access) |
Background Job Processing
Assets: Job payloads, processing state, worker credentials
Entry points: Job enqueue API, scheduled triggers, retry mechanisms
Key trust boundaries: API-to-queue, queue-to-worker, worker-to-external-services
| Priority Threats | STRIDE | DREAD Focus |
|---|
| Job payload tampering in queue | T | Exploitability: depends on queue auth |
| Privilege escalation via worker service account | E | Damage: workers often have broad access |
| Poison pill jobs crashing workers (retry storms) | D | Affected users: all queued jobs delayed |
| Sensitive data persisted in job payloads | I | Discoverability: queue inspection tools |
| Missing idempotency on retried jobs | T | Damage: duplicate side effects |
Phase 4: Framework-Aware Mitigations
After identifying threats and scoring risk, select mitigations appropriate to your stack.
Common Mitigations by Framework
| Threat | Django | Express/Node | Spring Boot | Rails |
|---|
| CSRF | {% csrf_token %} (on by default) | csurf middleware | CsrfFilter (on by default) | protect_from_forgery (on by default) |
| SQLi | ORM parameterized queries | knex parameterized, prisma | JPA/Hibernate parameterized | ActiveRecord parameterized |
| XSS | Auto-escaped templates | helmet + DOMPurify | Thymeleaf auto-escape | ERB auto-escape, sanitize helper |
| Auth | django.contrib.auth, django-allauth | passport.js, next-auth | Spring Security | Devise, Warden |
| Rate limit | django-ratelimit | express-rate-limit | bucket4j, resilience4j | rack-attack |
| Input validation | Django Forms, DRF serializers | joi, zod, express-validator | Bean Validation (@Valid) | Strong Parameters, ActiveModel validations |
| Session | Signed cookies (default) | express-session + secure store | Spring Session | Encrypted cookies (default) |
| File upload | FileField + validators | multer + type check | MultipartFile + validators | Active Storage + validators |
| Secrets | django-environ, vault | dotenv + vault | Spring Vault, @Value | credentials.yml.enc, vault |
Cross-Cutting Mitigations
| Control | Implementation |
|---|
| TLS everywhere | Enforce HTTPS, HSTS header, TLS 1.2+ only |
| Security headers | CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy |
| Dependency scanning | npm audit, pip-audit, bundle-audit, Dependabot/Renovate |
| Secret management | Never in code/env. Use HashiCorp Vault, AWS Secrets Manager, or cloud KMS |
| Logging | Structured, no PII/secrets, centralized, tamper-evident |
Verification Checkpoint
HARD GATE - Threat Model Completeness:
→ About to mark threat modeling complete → Verify ALL of the following with specific evidence. Any check fails → Go back and fill the gap before completing.
| Check | Required Evidence |
|---|
| DFD exists with trust boundaries marked | List each boundary and what data crosses it |
| Every trust boundary has STRIDE analysis | Reference specific threat IDs per boundary |
| Each STRIDE category has 3+ threats identified | Count per category, not just total |
| All threats scored 8+ DREAD have mitigations | Name the specific control for each |
| Mitigations reference actual framework tools | Not "add validation" but "Zod schema on POST /api/orders" |
| No OWASP Top 10 category left unaddressed | Map your threats to A01-A10, flag gaps |
| Residual risk documented for accepted threats | "Accepting X because Y, revisit by Z date" |
A threat model with blind spots is worse than no model (false confidence).
Phase 5: Actionable Output
A threat model that lives only in conversation context is a threat model that gets lost. After completing the analysis, produce concrete deliverables.
Write a Manual Actions File
Create a SECURITY-ACTIONS.md file in the project root (or alongside the feature code) containing all findings that require human decisions or manual steps. This file gets committed, making the actions visible in code review and git history.
Structure it like this:
# Security Actions: [Feature Name]
Generated: [date]
## Critical (DREAD 12-15) — Block release
- [ ] [Threat ID]: [Description] — [Specific action needed]
## High (DREAD 8-11) — Fix before release
- [ ] [Threat ID]: [Description] — [Specific action needed]
## Accepted Risk (DREAD 5-7) — Documented decisions
- [Threat ID]: [Description] — Accepting because [reason], revisit by [date]
## Configuration/Infrastructure Changes (require manual action)
- [ ] [Action]: [Details, who needs to do it, where]
Include in this file anything that cannot be automated: infrastructure changes, third-party service configuration, policy decisions, manual security testing needed, secrets to provision, DNS/certificate changes.
Auto-implement What You Can
After writing the actions file, look at the mitigations and identify which ones can be implemented directly in code right now. For each automatable fix:
- Plan the implementation — use available planning skills to create a structured implementation plan for the security controls
- Implement using subagents — dispatch up to 5 subagents in ONE message, one per independent fix (fixes that touch disjoint files). If >5 fixes, batch sequentially (5 per batch, wait for each batch before dispatching the next). Do NOT dispatch dependent fixes in parallel — the second must see the first's edits.
- Mark completed items — check off items in
SECURITY-ACTIONS.md as they are implemented, with a note about what was done
Examples of automatable fixes:
- Adding rate limiting middleware configuration
- Creating input validation schemas (Zod, Joi, Django Forms)
- Adding security headers (CSP, HSTS, X-Frame-Options)
- Setting up CSRF protection configuration
- Adding webhook signature verification boilerplate
- Creating authorization middleware/decorators
Examples of non-automatable actions (leave in the file):
- Provisioning API keys or secrets in a vault
- Configuring WAF rules or CDN settings
- Setting up monitoring/alerting thresholds
- Purchasing or configuring TLS certificates
- Organizational decisions (acceptable risk, compliance sign-off)
The goal: after this skill runs, the user has both a committed record of what needs doing AND as many controls as possible already in place.
Red Flags
| Thought | Reality |
|---|
| "Ad-hoc brainstorming is enough" | Misses 60% of threats vs. systematic STRIDE |
| "Everything is critical" | No prioritization = wrong fixes first. Use DREAD. |
| "We'll security review later" | 30x more expensive post-implementation |
| "Only external attackers matter" | Insider threats and supply chain are STRIDE categories too |
| "We use HTTPS so we're secure" | Transport security is one control among dozens |
