STRIDE is a threat-modeling framework developed at Microsoft in the late 1990s to give engineers a structured, repeatable way to ask "what could go wrong here?" instead of relying on whoever happens to be in the room to think of everything. It remains the most widely used framework for software threat modeling today.
Quick definition: STRIDE is a mnemonic for six categories of threat — Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege — each of which violates a specific security property a well-designed system should uphold.
The six categories
| Threat | Violates | Example |
|---|---|---|
| S Spoofing | Authentication | An attacker forges a JWT to impersonate another user |
| T Tampering | Integrity | An attacker modifies a request payload in transit |
| R Repudiation | Non-repudiation | A user denies performing an action because there is no audit log |
| I Information Disclosure | Confidentiality | Stack traces leak internal file paths to a public API response |
| D Denial of Service | Availability | Unauthenticated endpoints accept unbounded file uploads |
| E Elevation of Privilege | Authorisation | A standard user accesses an admin-only route due to missing RBAC checks |
How STRIDE is actually applied
STRIDE is rarely applied to a system as a whole — that produces a vague list nobody acts on. Instead, it's applied per element of a Data Flow Diagram: for every process, data store, external entity, and data flow you've mapped, you ask which of the six categories could apply to that specific element. A login API process gets checked against all six; a static data store typically doesn't need a Denial of Service pass in the same way a public endpoint does.
This element-by-element discipline is what makes STRIDE repeatable rather than dependent on one person's intuition. Two different engineers running STRIDE against the same DFD should land on largely the same threat list, because the categories and the elements to check them against are both fixed.
STRIDE vs. PASTA vs. LINDDUN
STRIDE isn't the only threat-modeling framework, though it's the one most teams start with. PASTA (Process for Attack Simulation and Threat Analysis) is a heavier, risk-centric process that ties threats directly to business impact — more common in organisations that need to justify security spend to non-technical stakeholders. LINDDUN mirrors STRIDE's structure but replaces the six categories with privacy-specific ones (Linkability, Identifiability, Non-repudiation, Detectability, Disclosure, Unawareness, Non-compliance), and is worth adding alongside STRIDE if your system handles personal data under GDPR or similar regulation.
For most teams, STRIDE is the right starting point: it's fast to learn, maps directly onto a DFD, and covers the threat categories that account for the overwhelming majority of real-world software vulnerabilities.
For a full worked example — threat-modeling an actual login flow end to end with STRIDE — see What Is Threat Modeling and Why Does It Matter?