Introduction
Most security problems aren't caused by a lack of skill — they're caused by a question nobody asked at design time. STRIDE is a threat modeling framework, originally developed by Microsoft, that gives engineering teams a structured way to ask the right questions before a system is built, not after it breaks.
Why it matters
Fixing a design flaw on a whiteboard costs a meeting. Fixing the same flaw in a live production system costs an incident response, potential customer trust damage, and in regulated industries, possibly a compliance conversation too. STRIDE moves security thinking to the cheapest possible point in the process — before code exists.
Technical explanation
STRIDE stands for six threat categories: Spoofing (impersonating a user or system), Tampering (altering data in transit or storage), Repudiation (denying an action with no way to prove otherwise), Information Disclosure (exposing data to someone who shouldn't see it), Denial of Service (making a system or service unavailable), and Elevation of Privilege (gaining higher access than intended).
The practical process starts with a data flow diagram — mapping users, processes, data stores, and the connections between them, along with trust boundaries (points where data moves from a less-trusted zone to a more-trusted one). Each element in that diagram gets checked against the STRIDE categories that realistically apply to it. A data store, for instance, is typically at risk from tampering, information disclosure, and denial of service, but rarely spoofing, since a database itself isn't "impersonating" anything.
For each threat identified, teams typically rate likelihood and impact, then assign a mitigation — a specific control that reduces or removes the risk. Mature teams often pair STRIDE with a scoring model like DREAD, and increasingly extend their threat modeling with frameworks like LINDDUN for privacy-specific threats or MAESTRO for AI/ML-specific risks, since STRIDE alone wasn't designed with model-level threats like prompt injection in mind.
Data Flow Diagram element → STRIDE threats to check
─────────────────────────────────────────────────────
External Entity (user) → Spoofing, Repudiation
Process (service/app) → All six categories
Data Store (database) → Tampering, Info Disclosure, DoS
Data Flow (network call) → Tampering, Info Disclosure, DoS
Real-world example
A recurring pattern across many documented incidents involves an API endpoint that trusts a user or object identifier sent directly from the client, without validating it against the authenticated session. This is a classic elevation-of-privilege scenario — one of the exact questions STRIDE asks a team to consider for any process handling user requests. This is described as a common, well-documented pattern rather than a specific named breach.
Common mistakes
Running STRIDE once at project kickoff and never revisiting it as the architecture changes.
Applying all six categories uniformly instead of focusing on which ones genuinely apply to each element type.
Skipping trust boundary mapping, which causes teams to miss where threats actually concentrate.
Treating the output as a static document instead of a living, actionable list with assigned owners.
Best practices
Run STRIDE during design review, with the engineers who actually built the system in the room.
Prioritize trust boundaries first — that's where the highest-value threats usually sit.
Re-run or update the threat model whenever the architecture changes meaningfully.
Keep every identified threat paired with a concrete mitigation, not just a note in a document.
Conclusion
STRIDE isn't complicated, and that's exactly its strength. Six categories, applied consistently at design time, catch a meaningful share of security issues before they ever reach production. The framework matters less than the habit it builds — a team that reflexively asks "can this be spoofed, tampered with, or misused?" before shipping anything new.