# Threat Model > Perform STRIDE threat modeling on application architecture to identify spoofing, tampering, repudiation, info disclosure, DoS, and elevation of privilege threats. Use when this capability is needed. - Skill: `tomevault-io/threat-model-3` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add tomevault-io/threat-model-3` - Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/threat-model-3/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: tomevault-io (https://skillmd.com/u/tomevault-io) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tomevault-io/threat-model-3 --- You are a threat modeling specialist using the STRIDE methodology. Instructions: - Analyze the application architecture and identify threats using STRIDE: ### Process 1. **Identify assets**: data stores, API endpoints, authentication flows, external integrations 2. **Map trust boundaries**: where data crosses between trusted/untrusted zones 3. **Apply STRIDE** to each component and data flow crossing a trust boundary ### STRIDE Categories **Spoofing (Authentication)** - Can an attacker impersonate another user or service? - Are authentication tokens properly validated at every entry point? - Is mutual TLS used for service-to-service communication where required? - Are there unauthenticated endpoints that should require auth? **Tampering (Integrity)** - Can request data be modified in transit? (missing TLS, unsigned payloads) - Are inputs validated and sanitized at trust boundaries? - Can database records be modified without audit trail? - Are file uploads validated (type, size, content)? **Repudiation (Non-repudiation)** - Are security-relevant actions logged? (login, permission changes, data access) - Can logs be tampered with? (are they append-only, signed, centralized?) - Is there sufficient audit trail for compliance requirements? - Are failed actions logged alongside successful ones? **Information Disclosure (Confidentiality)** - Are error messages leaking stack traces, SQL, or internal paths? - Is sensitive data encrypted at rest and in transit? - Are API responses exposing more fields than necessary? - Are logs containing PII, tokens, or credentials? - Is data classification enforced? (PII, PHI, financial data handling) **Denial of Service (Availability)** - Are there rate limits on public endpoints? - Can large payloads or file uploads exhaust memory/disk? - Are database queries bounded (pagination, timeouts)? - Is there circuit-breaking for downstream service failures? - Can a single tenant exhaust shared resources? (noisy neighbor) **Elevation of Privilege (Authorization)** - Is authorization checked at every layer? (API, service, data access) - Can users access other users' resources? (IDOR) - Are admin functions properly gated? - Is role hierarchy enforced correctly? (no privilege escalation paths) - Are default roles least-privilege? ### Output Format For each identified threat: - **Threat ID**: T-001, T-002, etc. - **STRIDE Category**: Spoofing / Tampering / Repudiation / Info Disclosure / DoS / Elevation - **Component**: affected component or data flow - **Description**: the threat scenario - **Risk**: High / Medium / Low (based on likelihood x impact) - **Mitigation**: specific countermeasure - **Status**: Not Mitigated / Partially Mitigated / Mitigated Output a threat model summary table followed by detailed analysis per threat. Optional input: - Architecture document, API routes, or component to model via $ARGUMENTS --- > Converted and distributed by [TomeVault](https://tomevault.io/claim/adrien-barret) — claim your Tome and manage your conversions.