Threat Modelling for APIs: OWASP API Top 10 Alignment

A traditional web app threat model can often treat "the application" as a small number of trust boundaries — browser, server, database. An API-first architecture typically has many more: each endpoint can enforce different authentication and authorisation rules, requests may pass through an API gateway, a service mesh, and multiple downstream microservices before completing, and a single logical operation can span several independently-owned services. Each hop is a place where an assumption about "the caller is already authenticated/authorised" can silently break.

APIs are also frequently consumed by other automated systems, not just human users through a browser, which changes the threat picture: rate limiting and abuse detection have to account for legitimate high-volume machine clients, and business-logic threats (like scraping an entire dataset one paginated request at a time) are easier to execute at scale against an API than against a UI.

The same DFD-based approach used for STRIDE applies to APIs, but the elements need to be granular enough to capture per-endpoint authorisation logic rather than treating "the API" as a single process. For each endpoint or operation, document: what object(s) it operates on, what authentication is required, what authorisation check determines whether the caller may act on the specific object requested (not just whether they're logged in), and what data the response returns.

That last point — being explicit about exactly what an endpoint's response includes — is what catches over-exposure issues, where an endpoint returns a full object with more fields than the consuming client actually needs, silently leaking internal fields to anyone who can call it.

The OWASP API Security Top 10 project maintains a ranked list of the most common and impactful API risk categories, and it's worth walking through the general themes it covers when threat modelling an API, rather than treating the general web OWASP Top 10 as sufficient on its own. The exact numbering and wording of the list is periodically revised by the project, so treat the specific ranking as something to check against the current published list rather than memorised — but the recurring themes have been consistent across revisions.

• •Broken object-level authorisation — an endpoint checks that the caller is authenticated but doesn't verify the caller is actually permitted to access the specific object referenced by an ID in the request (classic IDOR). This has consistently been called out as one of the most common and highest-impact API risk categories.
• •Broken authentication — weaknesses in how tokens, API keys, or session credentials are issued, validated, or rotated, including weak or missing rate limiting on authentication endpoints.
• •Broken object property-level authorisation — related to but distinct from object-level authorisation: a caller can read or write specific fields/properties on an object they shouldn't have access to, even if they're allowed to access the object itself (excessive data exposure and mass assignment both fall under this theme).
• •Unrestricted resource consumption — endpoints that don't limit request size, response size, number of records returned, or rate of requests, allowing a client to exhaust compute, memory, or cost via API calls alone.
• •Broken function-level authorisation — a caller can invoke administrative or privileged operations that should be restricted to a different role, often because authorisation is checked inconsistently across similar endpoints.
• •Server-side request forgery — an API accepts a URL or similar reference from the caller and fetches it server-side without validating the destination, allowing access to internal-only resources.
• •Security misconfiguration — overly permissive CORS policies, verbose error messages that leak stack traces, unnecessary HTTP methods enabled, missing security headers, and default credentials left in place.
• •Lack of protection from automated abuse / unsafe consumption of third-party APIs — insufficient controls against scripted abuse of business logic, and APIs that trust data pulled from third-party integrations without the same validation applied to direct user input.
• •Improper inventory management — undocumented, deprecated, or shadow API versions and environments (staging endpoints left internet-facing, old API versions never decommissioned) that fall outside normal security review.

A few threat patterns are specific enough to APIs that a generic STRIDE pass against a high-level architecture diagram tends to miss them unless the reviewer is deliberately looking. Mass assignment — where an endpoint blindly binds an entire request body to an internal object, letting a caller set fields like `isAdmin` or `accountBalance` that were never intended to be client-writable — is a good example; it only becomes visible once you're looking at the actual field-level contract of an endpoint, not just its trust boundary.

Pagination and enumeration abuse is another: an endpoint that's individually well-authorised can still leak an entire dataset if an attacker can iterate sequential IDs or unthrottled pages, one legitimate-looking request at a time. And GraphQL-specific risks — deeply nested queries causing resource exhaustion, or introspection left enabled in production revealing the full schema — need their own pass if GraphQL is in use, since REST-oriented checklists don't cover them.

For a system of any real size, treat API threat modelling as an ongoing practice tied to endpoint changes rather than a one-off exercise: review new or materially changed endpoints against the object-level and function-level authorisation questions above, keep an accurate, current inventory of every API version and environment that's reachable, and validate that rate limiting and payload/response size limits exist by default rather than being opt-in per endpoint. Pairing this with API-aware testing tooling that automatically probes for BOLA and mass assignment on new endpoints catches a large share of these issues before they reach production.