Threat Modeling a Small Web App

Threat modeling is a structured way of thinking about the security of an application before something goes wrong.

Instead of asking:

“How could someone attack this website?”

we start by asking:

“What are we building, what needs protection, and what could go wrong?”

Threat modeling helps developers and security teams identify risks early and decide which protections are most important.

Our Example Web App

Imagine we are building a small online learning platform.

A user can:

• Create an account
• Log in
• View lessons
• Submit comments
• Update their profile

The application has three main components:

        User
         ↓
    Web Browser
         ↓
    Web Application
         ↓
      Database

The application also communicates with external services such as an email provider.

Step 1: Identify What We Need to Protect

These are called assets.

For our application, important assets might include:

• User passwords
• Email addresses
• User profiles
• Authentication sessions
• Comments
• Application secrets
• Database information

Not every asset has the same level of importance.

For example, exposing a public lesson title is very different from exposing a user’s password.

Step 2: Identify Where Data Moves

Next, look at how information travels through the application.

For example:

User
 ↓
Login Form
 ↓
Web Server
 ↓
Authentication System
 ↓
Database

Each point where data enters, leaves, or changes is worth examining.

These are often called trust boundaries.

For example, we should not automatically trust information simply because it came from a browser.

Step 3: Ask “What Could Go Wrong?”

Now we can think about possible threats.

A useful framework is STRIDE.

Threat	Meaning
S — Spoofing	Pretending to be another user
T — Tampering	Modifying data without permission
R — Repudiation	Denying an action that was performed
I — Information Disclosure	Exposing information to unauthorized people
D — Denial of Service	Making a service unavailable
E — Elevation of Privilege	Gaining permissions you should not have

You don’t need to memorize STRIDE immediately. The important skill is learning to systematically ask what could go wrong.

Example: Login System

Let’s examine the login feature.

User
 ↓
Username + Password
 ↓
Web Application
 ↓
Authentication
 ↓
Database

Potential threats might include:

Spoofing:
Could someone gain access to another user’s account?

Information Disclosure:
Could passwords or sensitive account information accidentally be exposed?

Tampering:
Could someone modify account information they don’t own?

Denial of Service:
Could someone send excessive login requests and make the service unavailable?

The next step is to think about defenses.

Step 4: Add Security Controls

Once we’ve identified risks, we can consider appropriate protections.

For example:

Protect passwords

Use a modern password-hashing system rather than storing passwords as plain text.

Protect sessions

Use secure session management and appropriate cookie security settings.

Protect user input

Treat user input as untrusted and protect against vulnerabilities such as SQL injection and XSS.

Control permissions

Make sure users can only access resources they are authorized to access.

Protect sensitive information

Use encryption where appropriate and avoid exposing secrets in source code or error messages.

Monitor important actions

Logging can help identify suspicious activity and investigate security incidents.

Step 5: Think About the Worst Case

For each important threat, ask:

What could happen?
        ↓
How likely is it?
        ↓
What would be the impact?
        ↓
How can we reduce the risk?

This helps teams prioritize security work instead of trying to protect everything in exactly the same way.

Try It Yourself

Create a simple diagram for a fictional web application.

For example:

             Internet
                 ↓
            Web Browser
                 ↓
          ┌─────────────┐
          │ Web Server  │
          └─────────────┘
                 ↓
          ┌─────────────┐
          │  Database   │
          └─────────────┘

Now identify:

1. Assets

What information needs protection?

2. Entry points

Where can users provide information?

3. Trust boundaries

Where does information move between systems or components?

4. Threats

What could go wrong?

5. Defenses

What security controls could reduce each risk?

Try to identify at least five threats and one reasonable defense for each.

A Simple Threat Model

Your final result could look like this:

Component	Threat	Potential Impact	Defense
Login	Account takeover	Unauthorized access	Strong authentication
Comment system	XSS	Malicious content execution	Output encoding
Database	Unauthorized access	Data exposure	Access controls
API	Excessive requests	Service disruption	Rate limiting
User profile	Unauthorized modification	Data tampering	Authorization checks

The goal isn’t to predict every possible attack.

The goal is to systematically identify important risks before they become vulnerabilities.

Key Takeaways

• Threat modeling is a way to identify security risks before they become problems.
• Start by identifying your assets.
• Map how data moves through the application.
• Identify trust boundaries and entry points.
• Think about threats using a structured approach such as STRIDE.
• Choose security controls that reduce the identified risks.
• Threat modeling is most useful when it is done early and revisited as the application changes.

Next Lesson

Next, learn Authentication vs Authorization to understand the difference between proving who you are and determining what you are allowed to access.