Threat modeling

Threat modeling is a structured way of thinking like an attacker while a system is still on the whiteboard. A team draws how the system works, where data comes in and goes out, and where one part stops trusting another. Then it asks four plain questions, popularized by security engineer Adam Shostack: what are we building, what can go wrong, what are we going to do about it, and did we do a good enough job?

The drawing matters. Lines that cross a trust boundary, like requests from the public internet into your server or from your server into a third-party API, are where most attacks happen. The set of all those entry points is the attack surface. To avoid missing whole categories, many teams walk each element through STRIDE, a checklist created at Microsoft: Spoofing (pretending to be someone), Tampering (changing data), Repudiation (denying you did something), Information disclosure (leaks), Denial of service, and Elevation of privilege (getting more access than you should).

Each threat found gets a decision: fix it, reduce it, accept it consciously, or move it elsewhere (for example, to a payment provider). The result is a short document that lives next to the design and is revisited when the system changes. It is cheap compared with what it prevents: a missing permission check spotted in a design meeting costs an hour, the same flaw found in production after a breach can cost a company its customers. It also works outside software; journalists and activists build personal threat models to decide which protections are worth the effort for them.