Threat modeling APIs is often reduced to a short checklist around authentication and transport security. That rarely surfaces the issues that matter most. Real API risk tends to come from workflow design, trust assumptions between services, and weak authorization at object or action boundaries.
Focus on business actions, not just endpoints
A useful threat model begins with what the API actually enables. Create, export, approve, impersonate, administer, invite, bill, or trigger are more helpful frames than a list of routes. This makes it easier to identify where a caller may be able to do too much, bypass sequencing, or pivot through an internal dependency.
Review the hidden trust relationships
Modern APIs are rarely standalone. They interact with background workers, identity systems, analytics pipelines, AI services, and internal tooling. Those connections create the real attack surface. A route that appears harmless in isolation may become dangerous when combined with downstream side effects or stale authorization assumptions.
Questions worth asking
- What business action does this endpoint enable
- What inputs cross trust boundaries
- Where is authorization enforced and can it drift across services
- What assumptions exist about tenant identity, record ownership, or workflow state
- Which responses or asynchronous effects expose sensitive data
The payoff
Threat modeling done this way becomes directly useful to engineers. It leads to better object-level controls, cleaner service boundaries, and fewer late-stage surprises during testing or launch readiness reviews.