⚡ Module 3 · Foundations
The STRIDE Framework
STRIDE is the most widely-used threat categorization framework in the world. Developed at Microsoft, it gives you a structured checklist to ensure you never miss a category of threat.
🎯 Learning Objectives
- Name all six STRIDE categories and their definitions
- Map each STRIDE category to the CIA property it violates
- Identify the corresponding security property (mitigator) for each threat type
- Apply STRIDE to a simple system component to generate a threat list
- Recognize real-world attacks within each STRIDE category
1What is STRIDE?
STRIDE is a mnemonic — each letter is a category of threat. It was created by Microsoft engineers Loren Kohnfelder and Praerit Garg in 1999 and is still the industry standard today.
Why use a framework at all?
Human brains are bad at open-ended brainstorming for security. Without a structure, teams always miss whole categories. STRIDE solves this by giving you a complete checklist — if you've considered all six categories for each component, you've done a systematic job.
S
Spoofing
Pretending to be something or someone you're not. Impersonating a user, service, or identity.
🎭 Example: Attacker uses stolen tokens to log in as another user
T
Tampering
Unauthorized modification of data — in transit, at rest, or in memory.
✏️ Example: MITM attack changing payment amount in transit
R
Repudiation
Denying that an action occurred. The ability to say "it wasn't me" without the system being able to prove otherwise.
🙈 Example: No audit log → user denies they deleted records
I
Information Disclosure
Unauthorized exposure of confidential data — intentional or accidental.
📤 Example: Stack trace in error page reveals DB connection string
D
Denial of Service
Making a system unavailable to legitimate users — overwhelming resources or crashing services.
💥 Example: Flood of unauthenticated API calls crashes the login endpoint
E
Elevation of Privilege
Gaining permissions beyond what was granted. Escalating from user to admin, or unprivileged to privileged.
⬆️ Example: Bypassing authorization to access admin-only endpoint
2STRIDE → CIA Mapping & Mitigators
Each STRIDE category maps to a security property that, when present, prevents or limits that type of threat. Think of the mitigator as the antidote.
| STRIDE Category | CIA Property Violated | Security Mitigator | Real-World Controls |
|---|---|---|---|
| S — Spoofing | Authentication | Authentication | MFA, certificate pinning, OAuth, strong passwords |
| T — Tampering | Integrity | Integrity Controls | Digital signatures, HTTPS/TLS, checksums, input validation |
| R — Repudiation | Non-repudiation | Audit Logging | Immutable logs, digital signatures, SIEM, timestamps |
| I — Info Disclosure | Confidentiality | Confidentiality Controls | Encryption at rest/transit, access control, data masking |
| D — Denial of Service | Availability | Availability Controls | Rate limiting, auto-scaling, CDN, DDoS protection |
| E — Elevation of Privilege | Authorization | Authorization Controls | RBAC, least privilege, input validation, sandboxing |
3Applying STRIDE to a Component
The real power of STRIDE is how methodically you apply it. For each element in your Data Flow Diagram, you ask: "Is this element vulnerable to each STRIDE threat?"
Let's walk through a login endpoint as our example component:
Target Component: Login Endpoint (POST /api/login)
We'll apply all six STRIDE categories to the Login Endpoint box
Credential Stuffing / Account Takeover
Attacker uses leaked username:password pairs from other breaches to log in as real users. The endpoint trusts valid credentials without checking if they're being used by the legitimate owner.
Session Token Theft
Attacker steals a valid session cookie (via XSS, network sniffing) and presents it. The server sees a valid token and believes the attacker is the legitimate user.
Mitigations
MFA, bot detection, rate limiting on failed attempts, HttpOnly + Secure cookie flags, short session lifetimes, anomalous login detection.
Request Parameter Manipulation
Attacker intercepts the login POST request and modifies the username field — e.g., adding SQL injection payloads or changing the target account if the system uses username to determine session privileges after login.
Mitigations
HTTPS/TLS for all traffic, parameterized queries, server-side validation of all inputs, CSRF tokens.
No Login Audit Log
If login events (success, failure, source IP, timestamp) aren't logged, a compromised account owner can deny ever logging in from an unusual location, and forensic investigation is impossible.
Mitigations
Log all auth events (success/fail, IP, user-agent, timestamp) to a tamper-evident, centralized log store. Include request IDs for correlation.
Username Enumeration via Error Messages
If the login endpoint returns "wrong password" for valid usernames and "user not found" for invalid ones, attackers can enumerate all valid accounts — then focus brute force on those accounts.
Stack Trace in Error Response
An unhandled exception returns a full stack trace including framework versions, file paths, or connection strings — revealing internal architecture to attackers.
Mitigations
Generic error message for both wrong username and wrong password. Never expose stack traces in production. Log details server-side only.
Brute Force / Login Flood
Bot army sends millions of login attempts per minute. Without rate limiting, the endpoint exhausts database connections, CPU, or memory — crashing authentication for all users.
Mitigations
Rate limiting per IP and per account. CAPTCHA after N failures. Account lockout with exponential backoff. CDN/WAF DDoS protection upstream.
Role Bypass After Login
Login endpoint returns a JWT with a
role field. If that field is set client-side or trusted without server-side verification, an attacker modifies their token payload to claim admin role.Mitigations
Sign JWTs with strong keys server-side. Never trust client-supplied role claims. Verify authorization server-side on every request. Implement RBAC.
4STRIDE by Element Type
Not every STRIDE threat applies equally to every element type in a DFD. This shorthand table — STRIDE per Element — helps you focus:
| Element Type | S | T | R | I | D | E |
|---|---|---|---|---|---|---|
| External Entity (user, 3rd-party) | ✅ | — | ✅ | — | — | — |
| Process (API, service, function) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| Data Store (DB, file, cache) | — | ✅ | ✅ | ✅ | ✅ | — |
| Data Flow (network, IPC) | ✅ | ✅ | — | ✅ | ✅ | — |
Teaching Tip: The STRIDE Matrix Game
Create a blank STRIDE × Element matrix for students. Give them a simple system (e.g., a to-do app). Have them fill in the matrix with specific threats for each cell. Groups compete to find the most threats in 10 minutes. The competitive element dramatically improves engagement and retention.
5Knowledge Check
✏️ Exercise 3.1
Which STRIDE does audit logging mitigate?
Your team adds an immutable audit log recording every user action with timestamp, user ID, and IP address. Which STRIDE category does this primarily address?
✏️ Exercise 3.2
Which DFD element type has all 6 STRIDE threats?
When applying STRIDE per Element, which element type is applicable to ALL six STRIDE threat categories?
6Module Summary
Key Takeaways
- STRIDE = Spoofing · Tampering · Repudiation · Information Disclosure · Denial of Service · Elevation of Privilege
- Each category maps to a security mitigator: Auth → Integrity → Audit → Confidentiality → Availability → Authorization
- Apply STRIDE per element in your DFD — processes need all six, data stores skip Spoofing and EoP
- The framework's power is its completeness — it ensures you don't forget entire threat categories
- STRIDE generates the threat list; risk scoring then decides what to fix first