Teachers

Under construction

<aside> 🚧

This page is currently under construction. Please check back later.

</aside>

Introduction

In the previous section, we discussed developing a security mindset—learning to think like an attacker. But how do we apply this systematically? How do we ensure we're not missing critical threats? This is where threat modeling comes in. Threat modeling is a structured approach to identifying security threats, understanding their potential impact, and deciding how to address them. Think of it as a security brainstorming session with a framework to guide your thinking.

What is Threat Modeling?

At its core, threat modeling answers four key questions:

What are we building? → Understand the system
What can go wrong? → Identify threats
What are we going to do about it? → Plan mitigations
Did we do a good job? → Validate and iterate “this can be a bit complicated to this level.”

You don't need to be a security expert to do threat modeling. If you can describe how your system works and ask "what if?" questions, you can threat model.

Why Threat Model?

Without Threat Modeling Developers often discover security issues through:

Penetration testing (expensive, late in the process)
Security incidents in production (costly, damages trust)
Random code reviews (inconsistent, depends on reviewer knowledge)

With Threat Modeling, you proactively identify threats before writing code or during design:

Cheaper to fix issues during design than in production
Creates shared understanding among team members
Document security decisions for future reference
Helps prioritize security work based on risk

Key insight: Threat modeling shifts security from reactive "fix this vulnerability" to proactive "prevent this class of vulnerabilities".

The STRIDE Framework

STRIDE is a mnemonic developed by Microsoft to help categorize threats. Each letter represents a different type of threat:

Threat	Description	Security Property Violated
Spoofing	Pretending to be someone or something else	Authentication
Tampering	Modifying data or code without authorization	Integrity
Repudiation	Denying having performed an action	Non-repudiation
Information Disclosure	Exposing data to unauthorized parties	Confidentiality
Denial of Service	Making a system unavailable	Availability
Elevation of Privilege	Gaining permissions you shouldn't have	Authorization

STRIDE in Practice

Let's see how STRIDE applies to a simple login feature:

User ──── [Username/Password] ────> API ────> Database

Threat	Example	Possible Mitigation
Spoofing	Attacker uses stolen credentials to impersonate a user	Multi-factor authentication, account lockout
Tampering	Attacker modifies login request in transit	Use HTTPS, validate input server-side
Repudiation	User denies they logged in and performed actions	Audit logging with timestamps and IP addresses
Information Disclosure	Error messages reveal if username exists	Generic error messages ("Invalid credentials")
Denial of Service	Attacker floods login endpoint with requests	Rate limiting, CAPTCHA after failed attempts
Elevation of Privilege	Attacker manipulates response to gain admin role	Server-side role assignment, signed tokens

A Simple Threat Modeling Process

Here's a practical 5-step process you can apply to any feature or system:

Step 1: Draw Your System

Create a simple diagram showing:

Components (web app, API, database, external services)
Data flows (how information moves between components)
Trust boundaries (where privilege levels change)

Screenshot 2026-06-13 at 22.13.09.png

Step 2: Identify Assets

What are you protecting? List the valuable things in your system:

Asset	Why It's Valuable
User credentials	Access to accounts
Personal data (PII)	Privacy, regulatory compliance
Payment information	Financial fraud risk
Session tokens	Account takeover
Business data	Competitive advantage
System availability	Revenue, reputation

Step 3: Apply STRIDE to Each Component“ For each component and data flow, systematically ask STRIDE questions:

Step 4: Prioritize Threats

Not all threats are equal. Use a simple risk matrix to prioritize:

Screenshot 2026-06-13 at 22.20.44.png

Factors affecting likelihood:

Is the attack easy to perform?
Is there existing exploit code?
Is the component exposed to the internet?

Factors affecting impact:

What data could be compromised?
Could this affect all users or just one?
What's the regulatory/legal consequence?

Step 5: Plan Mitigations

For each prioritized threat, decide on a response:

| --- | --- | --- |

Threat Modeling Practical Example

Let's walk through a complete example. Consider this endpoint for updating user profiles:

@PutMapping("/api/users/{userId}/profile")
@PreAuthorize("isAuthenticated()")
public UserProfile updateProfile(
    @PathVariable Long userId,
    @RequestBody ProfileUpdateRequest request
) {
    return userService.updateProfile(userId, request);
}

Screenshot 2026-06-13 at 22.25.02.png

STRIDE Analysis

| --- | --- | --- | --- |

Resulting Secure Implementation

Week 10