A threat model is an analysis of a system’s security characteristics. It identifies vulnerabilities, shows how threat actors could exploit them, and connects attacks to affected components and consequences. section 2.2
Figure 1.3 To analyze attack vectors, we look at the three axes of API security: design, implementation, and infrastructure. We ask what vulnerabilities we expose in each axis, what they look like, and what their consequences are.
Analyze the API across design, implementation, and infrastructure; identify exposed vulnerabilities, their appearance, and their consequences. section 1.1
Build a useful threat model by asking four practical questions:
- What are we working on? Decompose the application and map its data flows, endpoints, services, databases, queues, and other relevant components. section 2.2
- What can go wrong? Brainstorm threats, consider how malicious users achieve their goals, and rank the resulting risks. section 2.2.2
- What are we going to do about it? Convert each threat into design, implementation, infrastructure, testing, or operational mitigations. section 1.1 section 2.7
- Did we do a good enough job? Validate the model, involve relevant stakeholders, verify responses, and improve the process through retrospectives. section 2.2.4
Threat modeling works best as a team activity involving engineering, product, QA, business stakeholders, and owners of different system components. Revisit it continuously, especially during major changes and at regular intervals. section 2.2 section 2.2.4
SQL injection on a collection endpoint
Suppose unconstrained query parameters reach non-parameterized database queries on GET /products. A malicious user may bypass access controls and affect the API and database. The model turns this path into actions: constrain user input, parameterize queries, and test the resulting controls. section 2.2
STRIDE supplies threat categories: spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. Tools can generate models from data-flow diagrams, but teams must review and adapt the results. section 2.7 section 2.2.2
Use the model to design focused security tests. Start with high-value, low-setup checks, then cover complex business flows and authorization scenarios revealed by the analysis. section 12.1 section 12.6
