Threat modeling has a reputation for being heavyweight and academic. It doesn't need to be. A lightweight threat model run by the engineers who built a feature, done consistently, catches more real issues than an occasional deep audit.
What threat modeling actually is
At its simplest: systematically asking "what could go wrong here, and what would an attacker actually do about it" for a specific system or feature — before it ships, not after.
STRIDE: a simple framework
STRIDE gives you six categories to walk through for any component:
- Spoofing — can someone pretend to be a user or service they're not?
- Tampering — can data be modified without authorization?
- Repudiation — can an action be denied due to lack of logging?
- Information Disclosure — can data be exposed to someone who shouldn't see it?
- Denial of Service — can the system be made unavailable?
- Elevation of Privilege — can someone gain access beyond what they're authorized for?
A practical session structure
- Draw the data flow. A simple diagram — client, API, database, external services — with data flow arrows. Whiteboard-quality is fine.
- Walk each trust boundary. Anywhere data crosses from one trust level to another (client to server, service to service) is where most real vulnerabilities live.
- Apply STRIDE at each boundary. For each arrow crossing a boundary, ask which STRIDE categories apply.
- Rank and assign. Not every finding needs fixing before launch — rank by impact and likelihood, and assign owners for what does.
Where to run this
New features touching authentication, payments, or user data are the highest-value candidates. You don't need to threat-model your internal admin dashboard with the same rigor as your public API.
Making it stick
The teams that keep doing this treat it as a 60-90 minute step before building anything with a new trust boundary — not a one-time compliance exercise. Bake it into your design-review template, and it stops feeling like extra work.