The first time someone walked me through STRIDE, I remember being almost surprised at how simple the mnemonic was compared to how much ground it actually covers. Six categories of threats, one for each letter, and suddenly a vague “what could go wrong here?” question turns into a structured checklist I can run against any component in a system. STRIDE has become one of my go-to frameworks precisely because it’s simple enough to use quickly but rigorous enough to catch real issues. This article breaks down each category, shows how I apply it in practice, and covers where it falls short.
What STRIDE Stands For
STRIDE was developed at Microsoft in the late 1990s as a mnemonic for six categories of security threats. Each letter maps to a violation of a specific security property:
- S — Spoofing: violating authentication, pretending to be someone or something you’re not.
- T — Tampering: violating integrity, modifying data or code without authorization.
- R — Repudiation: violating non-repudiation, being able to deny having performed an action.
- I — Information Disclosure: violating confidentiality, exposing data to unauthorized parties.
- D — Denial of Service: violating availability, preventing legitimate use of a system or resource.
- E — Elevation of Privilege: violating authorization, gaining capabilities beyond what’s permitted.
Walking Through Each Category
Spoofing
This is about identity. Can an attacker impersonate a legitimate user, service, or device? Examples include credential stuffing against a login form, forging authentication tokens, or spoofing a server’s identity in a man-in-the-middle attack. Mitigations typically involve strong authentication mechanisms — multi-factor authentication, mutual TLS between services, and properly validated certificates.
Tampering
Can data or code be modified in transit or at rest without detection? This covers everything from modifying a price parameter in an unprotected API request to altering log files to cover an attacker’s tracks. Mitigations include integrity checks like HMACs and digital signatures, parameterized database queries, and strict access controls on data stores.
Repudiation
Can a user or system deny having performed an action, and can you prove otherwise? Without proper logging, an attacker who deletes records or performs unauthorized transactions can plausibly claim they never did it. Mitigations center on comprehensive, tamper-resistant audit logging and digital signatures tied to specific actions.
Information Disclosure
Can sensitive data be exposed to someone who shouldn’t see it? This ranges from verbose error messages leaking stack traces, to misconfigured cloud storage buckets, to insufficient encryption of data at rest or in transit. Mitigations include encryption, strict access controls, and careful review of what gets included in logs and error responses.
Denial of Service
Can an attacker degrade or block legitimate access to a system or resource? This includes classic volumetric attacks, but also more subtle application-layer issues like an unbounded database query that a single malicious request can use to exhaust server resources. Mitigations include rate limiting, resource quotas, and architectural resilience like autoscaling and circuit breakers.
Elevation of Privilege
Can a user gain capabilities they shouldn’t have? This covers vertical privilege escalation — a regular user gaining admin rights — and horizontal escalation, like one customer accessing another customer’s data through an insecure direct object reference. Mitigations center on strict, consistently enforced authorization checks at every layer, not just the UI.
Applying STRIDE to a Real System
Here’s a simplified example applying STRIDE to a typical web application login flow, mapped against a basic data flow diagram:
flowchart LR
U[User Browser] -->|Credentials| A[Auth Service]
A -->|Query| D[(User Database)]
A -->|Session Token| U
A -->|Log Event| L[(Audit Log)]
| Component | Threat Category | Example Threat |
|---|---|---|
| User → Auth Service | Spoofing | Credential stuffing using leaked password lists |
| Auth Service → Database | Tampering | SQL injection modifying stored password hashes |
| Auth Service → Audit Log | Repudiation | Missing logs allow a user to deny a password change |
| Database | Information Disclosure | Unencrypted password hashes exposed in a breach |
| Auth Service | Denial of Service | Unthrottled login attempts exhaust server resources |
| Auth Service | Elevation of Privilege | Broken access control lets a user escalate to admin role |
Walking through each data flow and asking “which of the six STRIDE categories applies here?” is a fast, repeatable way to surface threats that a purely intuitive review would likely miss.
STRIDE vs. Other Methodologies
STRIDE is component-focused and works especially well at the design/architecture stage, applied per data flow or trust boundary. Methodologies like PASTA take a more attacker-centric, risk-driven approach across the entire lifecycle. In practice, I often use STRIDE for quick, per-component analysis during design reviews, and reserve heavier frameworks for high-risk systems that need a more exhaustive process.
Common Mistakes When Using STRIDE
- Applying it too broadly at once instead of methodically walking through each component and data flow.
- Stopping at threat identification without defining and tracking concrete mitigations.
- Treating all six categories as equally relevant everywhere — not every component has meaningful exposure to every category, and forcing the exercise can waste time.
- Doing it once and never revisiting it as the architecture evolves.
- Skipping the data flow diagram, which makes the exercise far less systematic and more prone to missed threats.
Best Practices
- Always start with a simple data flow diagram — it doesn’t need to be elaborate, just accurate enough to identify trust boundaries.
- Walk through each element (process, data store, data flow, external entity) against all six STRIDE categories methodically.
- Prioritize findings by realistic likelihood and impact rather than treating every identified threat as equally urgent.
- Document mitigations as trackable backlog items, not just notes in a meeting.
- Revisit the model whenever the architecture changes meaningfully.
FAQs
Is STRIDE only useful for web applications? No — it applies to any system with identifiable components and data flows, including APIs, mobile apps, IoT devices, and cloud infrastructure.
How long should a STRIDE session take? For a single component or feature, thirty to sixty minutes is usually enough. Reserve longer sessions for entire system reviews or high-risk architecture changes.
Do I need special software to do STRIDE threat modeling? No — a whiteboard, a simple diagramming tool, and a spreadsheet or table are enough. Dedicated tools like Microsoft’s Threat Modeling Tool or OWASP Threat Dragon can help formalize the process for larger teams.
How does STRIDE relate to the OWASP Top 10? They’re complementary. STRIDE helps you systematically identify threat categories at the design stage; the OWASP Top 10 lists common vulnerability classes that often result when those threats aren’t properly mitigated in the implementation.
Conclusion
STRIDE earns its place as one of the most widely used threat modeling frameworks because it’s genuinely simple to apply without sacrificing rigor. Walking a data flow diagram through each of the six categories turns an abstract “what could go wrong” question into a concrete, repeatable checklist. It won’t replace deeper risk-centric methodologies for your highest-stakes systems, but as a fast, consistent habit for every design review, it’s hard to beat.
