Threat Modeling and Trust Boundaries
Problem
Your order portal requires login. A customer changes an order number in a request and sees somebody else's delivery address. Authentication worked, but the application trusted a request it should have checked.
Solution — Threat Modeling
Describe what you are protecting and how information moves through the system. An asset is something valuable, such as customer data. A threat is a possible harmful event, such as unauthorized disclosure. A vulnerability is a weakness that makes it possible, such as a missing ownership check. Risk considers how likely that harm is and how serious its consequences would be.
A trust boundary separates areas with different trust assumptions or privileges. A browser sending a request to your server crosses one. Being logged in does not make every value sent by that browser trustworthy.
For each boundary, ask what could go wrong and which checks belong there. The server must verify that this customer may access this order. Input validation, authorization, limited permissions, and monitoring provide different layers of protection.
Revisit the model when data flows, features, or dependencies change.
Core idea: threat modeling connects valuable assets, possible harm, and system weaknesses so that protections address specific risks.