STRIDE Threat Model Components: Complete Guide to the 6 Categories

STRIDE is a threat classification framework developed by Microsoft engineers Loren Kohnfelder and Praerit Garg in 1999, later formalized and popularized by Microsoft’s Secure Development Lifecycle (SDL) team, including Adam Shostack. STRIDE is an acronym for six categories of security threats: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege.

The purpose of STRIDE is to provide architects, developers, and security engineers with a repeatable method for identifying threats to a system during design, before code is written. Each STRIDE category maps directly to a security property that a system is expected to uphold:

STRIDE is typically applied to a Data Flow Diagram (DFD) of a system, where each element, process, data store, data flow, and external entity, is systematically evaluated against the six threat categories. This element-by-element analysis is what separates STRIDE from ad hoc brainstorming: it forces coverage rather than relying on an analyst’s intuition about what might go wrong.

The following sections define each STRIDE component in detail, with examples, affected system elements, and concrete mitigations.

The 6 STRIDE Threat Model Components

Spoofing

Definition: Spoofing is a threat category in which an attacker assumes the identity of another user, process, or system component. It directly violates authentication, the property that guarantees an entity is who or what it claims to be.

Spoofing threats occur wherever a system trusts an identity claim without adequately verifying it. This includes user login flows, service-to-service authentication, network-layer identity (IP/MAC addresses), and even physical device identity in IoT contexts.

Real-world examples:

• Credential stuffing against a login endpoint using leaked username/password pairs from other breaches.
• DNS spoofing/cache poisoning to redirect users to a malicious server impersonating a legitimate domain.
• API key theft allowing an attacker to call backend services as a trusted microservice.

Commonly affected elements:

• External entities (users, third-party systems)
• Authentication processes and login forms
• Data flows carrying credentials or tokens
• Service-to-service communication channels

Mitigations:

• Enforce strong, phishing-resistant authentication (FIDO2/WebAuthn, mutual TLS for services).
• Implement multi-factor authentication (MFA) on all privileged accounts.
• Use short-lived, signed tokens (e.g., JWT with proper signature validation) instead of static API keys.
• Validate certificates and enforce DNSSEC to prevent domain/identity spoofing.
• Rate-limit and monitor authentication endpoints to detect credential-stuffing patterns.

Tampering

Definition: Tampering is the unauthorized modification of data, code, or system state. It violates integrity, the guarantee that data and processes remain accurate and unaltered except by authorized actors.

Tampering can occur at rest (databases, config files, binaries) or in transit (network traffic, inter-process communication). It also includes tampering with logs to hide evidence, which often overlaps with repudiation.

Real-world examples:

• Modifying a price parameter in an unauthenticated API request to change checkout totals in an e-commerce app.
• Man-in-the-middle (MITM) attacks that alter data packets between a client and a server over unencrypted HTTP.
• Injecting malicious code into a CI/CD pipeline artifact before deployment (supply chain tampering).

Commonly affected elements:

• Data stores (databases, file systems, caches)
• Data flows between client and server, or between services
• Configuration files and infrastructure-as-code templates
• Build and deployment pipelines

Mitigations:

• Enforce TLS 1.2+ for all data in transit; disable legacy protocols.
• Use cryptographic integrity checks (e.g., HMACs and digital signatures) on critical data and artifacts.
• Apply strict input validation and server-side authorization checks, never trust client-supplied values for pricing, permissions, or IDs.
• Implement database-level access controls and audit triggers for sensitive tables.
• Sign build artifacts and verify signatures before deployment (SLSA framework, Sigstore).

Repudiation

Definition: Repudiation occurs when a user or system can deny having performed an action, and the system lacks sufficient evidence to prove or disprove the claim. It violates non-repudiation, the property that ensures actions can be confidently attributed to their originator.

Repudiation threats are closely tied to logging and audit trail design. Weak or missing logs, or logs that can be altered post-hoc, are the primary root cause.

Real-world examples:

• A user disputes a financial transaction, and the system has no signed, timestamped record linking that transaction to their authenticated session.
• An insider deletes application logs after performing an unauthorized data export.
• A microservice makes a privileged API call, but the request lacks a correlation ID or an identity claim, making it impossible to trace it after the fact.

Commonly affected elements:

• Logging and audit subsystems
• Transaction processing workflows
• Data flows lacking sender authentication
• Administrative and privileged-access processes

Mitigations:

• Implement centralized, tamper-evident logging (write-once storage, cryptographic log chaining).
• Timestamp and digitally sign critical transactions.
• Attach authenticated identity and correlation/request IDs to every privileged action.
• Restrict log deletion and log modification permissions separately from application admin roles.
• Retain logs per compliance requirements (e.g., PCI DSS, SOC 2) with defined retention periods.

Information Disclosure

Definition: Information disclosure is the exposure of information to an individual or system not authorized to access it. It violates confidentiality, the property that restricts data access to authorized parties only.

This category covers both direct data leaks (e.g., exposed databases) and indirect leaks (e.g., verbose error messages revealing stack traces or internal architecture).

Real-world examples:

• A misconfigured cloud storage bucket (e.g., AWS S3) left publicly readable, exposing customer PII.
• A REST API returning detailed stack traces or internal server paths in error responses.
• Insecure Direct Object Reference (IDOR) allowing a user to change a URL parameter and view another user’s records.

Commonly affected elements:

• Data stores (databases, object storage, backups)
• API responses and error-handling logic
• Data flows over unencrypted channels
• Logs that inadvertently capture sensitive data (passwords, tokens, PII)

Mitigations:

• Encrypt sensitive data at rest and in transit; use field-level encryption for highly sensitive attributes.
• Enforce object-level authorization checks (verify that the requester owns or is authorized to access the requested resource).
• Return generic error messages to clients; log detailed errors on the server side only.
• Apply least-privilege IAM policies to cloud storage and databases; audit public-access configurations continuously.
• Mask or redact sensitive fields in logs and monitoring dashboards.

Denial of Service

Definition: Denial of Service (DoS) is a threat that degrades or disables a system’s availability to legitimate users. It violates availability, the guarantee that authorized users can access a system and its resources when needed.

DoS threats include network-layer floods, application-layer resource exhaustion, and logic-based abuse (e.g., repeatedly triggering expensive operations).

Real-world examples:

• A volumetric DDoS attack flooding a public-facing web application with traffic from a botnet.
• An attacker submitting requests that trigger unbounded, expensive database queries (algorithmic complexity attack).
• Exhausting a serverless function’s concurrency limits or a cloud account’s cost quota (economic denial of sustainability).

Commonly affected elements:

• Public-facing processes (web servers, APIs, load balancers)
• Shared infrastructure (databases, message queues)
• Rate-limited or quota-bound services (serverless functions, third-party APIs)

Mitigations:

• Deploy DDoS protection at the network edge (CDN/WAF services with volumetric mitigation).
• Implement rate limiting and request throttling per user/IP/API key.
• Set resource quotas, timeouts, and circuit breakers on expensive operations.
• Design for graceful degradation (queueing, backpressure) rather than hard failure under load.
• Monitor for abnormal traffic patterns and automate scaling or blocking responses.

Elevation of Privilege

Definition: Elevation of Privilege (EoP) occurs when an attacker gains capabilities or access rights beyond what was originally granted. It violates authorization, the property that restricts actions to those explicitly permitted for a given identity.

EoP is often the end goal of an attack chain that begins with spoofing or tampering, making it the highest-severity STRIDE category in most risk models.

Real-world examples:

• A standard user exploiting a broken access control flaw to access admin-only API endpoints.
• A containerized application escaping its container boundary to gain host-level root access.
• SQL injection used to bypass application logic and execute commands with database administrator privileges.

Commonly affected elements:

• Authorization and access-control processes
• Privileged processes (admin panels, background jobs running as root/system)
• Trust boundaries between containers, VMs, or cloud tenants
• Input-handling code vulnerable to injection

Mitigations:

• Apply the principle of least privilege to every user, service account, and process.
• Enforce role-based (RBAC) or attribute-based (ABAC) access control on every sensitive operation, checked server-side.
• Use parameterized queries/prepared statements to eliminate injection-based privilege escalation.
• Run containers and services with minimal capabilities; avoid running processes as root.
• Regularly patch and audit privilege-escalation vectors (e.g., kernel, container runtime, and hypervisor CVEs).

How to Apply the STRIDE Threat Model

Step 1: Decompose the System

Build a Data Flow Diagram (DFD) representing the system’s architecture. A DFD includes four element types:

Draw trust boundaries (dashed lines) around regions where privilege or trust level changes, for example, between the public internet and an internal network, or between two microservices owned by different teams. Trust boundaries are where most exploitable threats concentrate.

Step 2: Apply STRIDE Per Element

For each DFD element, evaluate which STRIDE categories realistically apply. Microsoft’s original guidance maps categories to element types:

Work through each element systematically rather than brainstorming freely, this is what makes STRIDE repeatable and auditable.

Step 3: Prioritize Threats

Once threats are enumerated, rank them by severity and likelihood. STRIDE does not include a built-in scoring mechanism, so most teams pair it with a separate risk-rating model, such as DREAD or CVSS, to assign a numeric priority.

Step 4: Document and Mitigate

For each identified threat, record:

• Threat description and affected element
• STRIDE category
• Risk rating
• Proposed mitigation
• Owner and status (open/mitigated/accepted)

Tooling options:

• Microsoft Threat Modeling Tool (TMT): free, DFD-based, auto-generates STRIDE threats per element.
• OWASP Threat Dragon: open-source, web and desktop, DFD-based with STRIDE built in.
• IriusRisk: commercial platform with automated threat libraries and SDLC integration.
• pytm / threat-modeling as code: code-defined threat models for CI/CD integration.

SDLC integration best practices:

• Run threat modeling during the design phase, before implementation begins.
• Re-run or update the model when architecture changes significantly (new trust boundary, new external integration).
• Store threat models as versioned artifacts alongside architecture documentation.
• Gate high-risk findings behind mandatory mitigation before release, similar to a security code review gate.

STRIDE Examples in Practice

Example 1: E-Commerce Checkout Flow

System: User browser → Web application (process) → Payment API (external process) → Order database (data store).

Example 2: Cloud Microservice Authentication

System: Client → API Gateway (process) → Auth Service (process) → User store (data store).

• Spoofing: A forged JWT with a weak signing algorithm (alg: none) bypasses authentication → mitigated by enforcing strict algorithm allow-lists and signature validation.
• Tampering: An attacker modifies a service-to-service message on an internal network without encryption → mitigated by enforcing mTLS between all internal services, not just external-facing ones.
• Elevation of Privilege: A compromised low-privilege service account calls an internal admin API with no scope restriction → mitigated by issuing narrowly scoped tokens per service and validating scopes on every call.

Limitations of STRIDE and When to Use It

Strengths:

• Simple, memorable structure that non-security engineers can learn quickly.
• Systematic coverage via DFD element mapping reduces blind spots.
• Vendor-neutral and free; supported by mature tooling (Microsoft TMT, OWASP Threat Dragon).
• Effective at the design stage, before code exists to test.

Limitations:

• No built-in risk scoring: STRIDE identifies threats but does not rank them; teams must pair it with DREAD, CVSS, or a custom risk matrix.
• Manual and time-intensive for large or rapidly changing systems; scaling STRIDE across microservice architectures requires tooling or automation.
• Analyst-dependent: the quality of output depends heavily on the completeness of the DFD and the analyst’s domain knowledge.
• Not attacker-centric: STRIDE is asset/system-centric, not focused on attacker motivation or business impact, which frameworks like PASTA address more directly.

Comparison to other threat modeling frameworks:

When to use STRIDE: Use STRIDE as the default framework for architecture-level threat modeling during design reviews, especially when a DFD is available or can be produced. Pair it with DREAD or CVSS for prioritization, and consider PASTA or LINDDUN as complements when business-risk alignment or privacy analysis is a specific requirement.

STRIDE’s true power lies in breaking down complex systems into its six core components: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. Master these components in our complete STRIDE Threat Model Guide, and you can systematically identify threats in any architecture.

Conclusion

STRIDE’s six components, Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege, provide security teams with a structured, repeatable method for identifying threats to authentication, integrity, non-repudiation, confidentiality, availability, and authorization. Applied systematically against a Data Flow Diagram, STRIDE surfaces threats that ad hoc reviews miss, and it integrates cleanly into design-phase reviews within any SDLC. It is not a complete risk management solution on its own; pair it with a scoring model like DREAD and, where relevant, complementary frameworks like PASTA or LINDDUN. Teams building or reviewing system architecture should incorporate STRIDE threat modeling before implementation begins, using tools such as the Microsoft Threat Modeling Tool or OWASP Threat Dragon to formalize the process.