Threat Modeling for Web Applications — Make the Attack Map Before They Do

"If you wait until the smoke alarm goes off to look for the fire, congratulations: you’re bad at threat modeling." — probably me, at 2 a.m.

You’ve already met the OWASP Top 10 (we put the band on stage earlier), and you’ve gotten your hands dirty with covert ops, antiforensics, and OPSEC from the System Hacking module. Now it’s time to stop reacting and start predicting. Threat modeling is the superpower that lets you design defenses like a chess grandmaster — you see the threats before they become headlines.

What is threat modeling (for web apps & APIs)?

Threat modeling is the structured practice of identifying assets, mapping how data flows, enumerating what can go wrong (threats), and deciding what to fix first. Think of it as building a detailed map of the building before you decide where to lock the doors, reinforce the windows, and hide the valuables.

This is the logical progression from our previous modules: you already understand how attackers hide (LotL, steganography, antiforensics) and the common vulnerabilities attackers exploit (OWASP Top 10). Threat modeling connects those dots so you can prioritize mitigations that matter.

The 6-step playbook (practical, actionable)

1. Define scope & assets

   • What part of the web app / API are you modeling? Entire app, a microservice, or a single endpoint?
   • Assets = user data, tokens, admin interfaces, secrets, business logic.

2. Draw a Data Flow Diagram (DFD)

   • Boxes for processes, data stores, external entities (users, 3rd-party services), and arrows for data flows.
   • Label trust boundaries (browser ↔ API, API ↔ database, API ↔ external OAuth provider).

3. Identify threats using a model (STRIDE, PASTA, LINDDUN)

   • STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) works brilliantly for web apps.

4. Map threats to vulnerabilities (OWASP Top 10 + implementation issues)

   • Example: A login endpoint without rate limiting → Brute force (STRIDE: Spoofing / DoS) → OWASP A07 (Identification & Auth failures).

5. Prioritize using risk scoring

   • Use CVSS-like criteria: impact × likelihood. Keep it simple: High/Medium/Low if you’re starting.

6. Define mitigations, verification, and monitoring

   • Fixes, plus detection (logging + SIEM) and continuous validation (SAST/DAST, fuzzing, pentesting).

Example: Quick threat model for a typical API login + upload flow

Imagine a web app with endpoints: /api/login, /api/upload, /api/user/profile.

DFD highlights:

• External user (browser) → /api/login → Auth service → Token issued
• User → /api/upload (multipart) → File storage (S3) → processing microservice

Threats (STRIDE) and mapping to OWASP:

Ask: "If an attacker can bypass the upload validation, can they write to a location that gets executed?" That single question often exposes an elevation-of-privilege chain.

Tools & techniques (not just theory)

• Draw DFDs: OWASP Threat Dragon, draw.io, or whiteboard + phone camera (yes, seriously).
• Automated mapping and threat lists: Microsoft Threat Modeling Tool
• Attack-path analysis: use Burp Suite + API logs to simulate chained attacks.
• Continuous checks: SAST for code issues, DAST for runtime, and interactive application security testing (IAST) where possible.

How this ties to offensive ops & OPSEC (and why defenders should care)

From System Hacking you know how attackers hide and persist. Threat modeling asks: Where would a stealthy attacker go first? How would they persist? Include these persistence avenues in the model:

• Logs and logging integrity: If an attacker can tamper with logs (LotL techniques), how will you detect abnormal behavior? Include detection tamper-resistance in your mitigations.
• Upload and file handling: Attackers often use file uploads as persistence/backdoors (look at previous module’s LotL examples). Harden processing paths, isolate file execution.
• Third-party services: Supply chain is a persistence vector (malicious library injection). Track and include dependencies in the model.

Defense is not just patching bugs — it’s making sure the attacker’s eviction plan is visible and enforceable.

Common pitfalls (and how to avoid them)

• Treating threat modeling as a checkbox. It’s a living document.
• Modeling only the happy path. Attackers love edge cases.
• Forgetting monitoring: Without detection, mitigations are guesses.
• Over-relying on one framework. STRIDE is great; LINDDUN helps with privacy; PASTA gives business context.

Quick checklist (use during sprint planning)

• Did we draw a DFD and mark trust boundaries?
• Did we map each data flow to STRIDE threats?
• Did we cross-reference OWASP Top 10 for each component?
• Are mitigations prioritized by risk + feasibility?
• Is there a logging & detection plan that is tamper-aware?
• Did we include supply chain/dependencies in scope?

Parting line (mic drop)

Threat modeling is less about building a perfect fortress and more about building the right fortress in the right place. If your threat model shows attackers are most likely to pivot through your API file upload path, spend your time there — not polishing token storage on a feature nobody uses anymore.

Summary takeaways:

• Draw the system. Name the assets. Map the flows. Mark trust boundaries.
• Use STRIDE (or a complementary method) to enumerate threats and map them to OWASP vulnerabilities.
• Prioritize by realistic attacker techniques (remember persistence and evasion tactics from System Hacking).
• Mitigate, then instrument: fixes + detection + continuous validation.

Now go build a DFD, find the weird edge-case flow that would let someone sneak in, and make that flow boring to attackers. Boring is underrated.

"Threat modeling is like rehearsal. If you practice the disaster, you get better at not having one."