Most developers think about security during code review — if at all. But the most impactful security decisions happen during the design phase, before a single line of code is written. Threat modeling is the practice of systematically identifying what can go wrong with your system and deciding what to do about it. It's not just for security teams; every developer should understand the basics.
At its core, threat modeling answers four questions: What are we building? What can go wrong? What are we going to do about it? Did we do a good job? You can apply this to an entire application architecture or a single feature. The key is to think adversarially — put yourself in the attacker's shoes and ask how each component could be abused, bypassed, or broken.
Microsoft's STRIDE model categorizes threats into six types: Spoofing (pretending to be someone else), Tampering (modifying data), Repudiation (denying actions), Information Disclosure (leaking data), Denial of Service(crashing systems), and Elevation of Privilege (gaining unauthorized access). Walk through each category for every component in your data flow diagram. This structured approach ensures you don't miss entire classes of vulnerabilities.
Start by drawing how data moves through your system: users, browsers, API servers, databases, third-party services. Mark trust boundaries — the lines where data crosses from one trust level to another, like from the public internet to your internal network. Every trust boundary is a high-priority area for threats. A simple whiteboard diagram is enough; the goal is clarity, not perfection.
Not every threat needs a fix. Rank threats by likelihood and impact using a simple high/medium/low matrix. A SQL injection vulnerability on a public-facing login form is high-likelihood, high-impact — fix it immediately. A theoretical timing attack on an internal health-check endpoint is low on both axes — document it and move on. For each high-priority threat, define a specific mitigation: input validation, encryption, access control, rate limiting, or monitoring.
Threat modeling works best when it's lightweight and continuous. Don't save it for quarterly security reviews. Instead, spend 15 minutes threat-modeling every new feature during sprint planning. Over time, thinking adversarially becomes second nature — and your applications become fundamentally more resilient.