Threat Modeling For APIs

Why this matters

APIs expose business capabilities and data. Threat modeling helps you find security and privacy risks early, decide what to fix first, and communicate trade-offs. As an API Engineer, you will:

• Design new endpoints and choose safe defaults (auth, rate limits, input validation).
• Review OpenAPI/GraphQL schemas and spot risky patterns before code ships.
• Plan mitigations and create a clear backlog for security work.
• Explain risks and controls to teammates and stakeholders.

Who this is for

• API Engineers and Backend Developers building or reviewing HTTP/gRPC APIs.
• Tech Leads who need repeatable, lightweight security reviews.
• DevOps/SRE engineers integrating gateways, service mesh, or identity.

Prerequisites

• Basic HTTP/REST knowledge (verbs, status codes) or familiarity with GraphQL/gRPC.
• Understanding of authentication and authorization basics (e.g., OAuth 2.0, JWT).
• Comfort reading API specs (OpenAPI/GraphQL SDL) and simple sequence diagrams.

Concept explained simply

Threat modeling is a structured way to ask: What are we building? What can go wrong? What are we doing about it? Did we do a good job? For APIs, we look at entry points (endpoints), data flows, trust boundaries, and controls.

Mental model

Use this simple loop:

1. Define scope and assets: which API, data, and operations matter most.
2. Map data flows: client → gateway → service(s) → data store(s) → third parties.
3. Identify threats using a checklist (e.g., STRIDE) across each flow and boundary.
4. Rate risk (likelihood × impact) and prioritize.
5. Select mitigations; create actionable backlog items.
6. Validate with tests and monitoring; repeat on changes.

Quick STRIDE reminder (API-focused)

• Spoofing: pretending to be someone/something (missing auth, weak auth, broken mTLS).
• Tampering: changing data in transit or at rest (no integrity, injection, replay).
• Repudiation: denying actions without proof (insufficient logging/audit).
• Information Disclosure: leaking data (excessive data, verbose errors).
• Denial of Service: making the API unavailable (abuse, expensive queries).
• Elevation of Privilege: gaining higher access (broken authorization, IDOR).

A lightweight API threat modeling workflow

1. Scope: Choose one business capability (e.g., Order Creation API).
2. Assets & actors: Sensitive data (PII, tokens), services, external clients.
3. Data flow diagram (text is fine): Enumerate components and trust boundaries.
4. Threats: Walk each step with STRIDE; note concrete scenarios.
5. Risk rating: Small 2×2 matrix (Low/High likelihood × Low/High impact) or numeric.
6. Mitigations: Map threats to controls (authZ, validation, rate limits, logging, mTLS, etc.).
7. Validation: Add tests, monitoring, and playbooks.

Worked examples

Example 1: Public REST endpoint — POST /orders

DFD (text): External Client → API Gateway (TLS) → Orders Service → Payments Service → Database. Trust boundaries: Internet↔Gateway, Gateway↔Services, Services↔DB, Service↔Third-party payment.

Key threats:

• Spoofing: Stolen access token used to create orders.
• Tampering: Replay of POST requests creating duplicates.
• Information Disclosure: Error messages leaking payment details.
• DoS: Bot floods POST /orders.
• EoP: User creates order for another account (IDOR).

Mitigations:

• OAuth 2.0 access tokens with short TTL; token introspection at gateway.
• Idempotency keys for POST; anti-replay window for signed requests.
• Structured error handling; do not echo sensitive fields.
• Rate limiting and burst controls at gateway; circuit breakers downstream.
• Authorization checks on ownership; never trust client-provided user IDs.

Example 2: Service-to-service gRPC with mTLS

DFD: API Gateway → BFF → Inventory Service ↔ Pricing Service ↔ Cache/DB. Trust boundaries: Gateway↔Mesh, Mesh↔Services.

Key threats:

• Spoofing: Rogue service calling Inventory.
• Tampering: Request altered in transit.
• Repudiation: Missing traceability of who called what.
• EoP: BFF calling privileged Inventory RPCs.

Mitigations:

• mTLS with SPIFFE/SVID or similar identities; rotate certs.
• Signed requests (mTLS ensures integrity); disable plaintext.
• Distributed tracing with unique IDs; immutable audit logs.
• Service-level authorization policies; least-privilege RPC allowlists.

Example 3: GraphQL endpoint

DFD: Web Client → GraphQL Gateway → Resolver Services → DB. Boundary: Internet↔Gateway.

Key threats:

• DoS: Expensive nested queries and N+1 data fetches.
• Information Disclosure: Over-fetching returns fields user should not see.
• EoP: Field-level auth gaps on nested resolvers.

Mitigations:

• Query complexity/depth limits; timeouts; cost analysis per type/field.
• Field-level authorization; default to least privilege.
• Persisted queries/whitelisting; disable introspection in production UIs.

Example 4: Inbound webhooks (bonus)

Threats: Spoofed webhook sender; payload tampering; replay; path traversal in file callbacks.

Mitigations: Verify HMAC signatures with timestamp and tolerance; unique delivery IDs; store-and-forward; strict content-type and size limits; safe file handling.

API threat modeling checklist

• [ ] Scope one capability or endpoint group.
• [ ] List assets: data, credentials, secrets, service identities.
• [ ] Draw or describe data flows and trust boundaries.
• [ ] Walk STRIDE per flow and boundary; write concrete scenarios.
• [ ] Rate risks and prioritize top items.
• [ ] Select controls and update API design/spec.
• [ ] Add tests, monitoring, and logging requirements.
• [ ] Revisit on schema changes or new integrations.

Exercises

Do these hands-on tasks. The quick test is available to everyone; only logged-in users get saved progress.

Exercise 1: Model a profile update API

Goal: Create a concise text DFD and threats list for PATCH /users/{id}.

1. Write a one-line DFD: Client → Gateway → Users Service → DB.
2. Mark trust boundaries.
3. List 5 threats using STRIDE (focus on authN/Z, IDOR, disclosure, replay).
4. Propose specific mitigations for each threat.

Tips

• Assume JWT auth with user roles.
• Assume clients may try to update another user.

Exercise 2: Prioritize risks with a 2×2 matrix

Goal: Take your Exercise 1 threats and place them into Likelihood vs Impact (Low/High). Then list top 3 backlog items.

1. Define criteria: what makes likelihood high? what makes impact high?
2. Place each threat.
3. Create actionable backlog tickets (e.g., "Enforce object ownership check in PATCH").

Common mistakes and self-check

• Mistake: Staying abstract. Self-check: Are your threats concrete scenarios tied to a specific endpoint and data?
• Mistake: Ignoring authorization details. Self-check: Do you check ownership and role at every resolver/handler?
• Mistake: Over-relying on gateway. Self-check: Do services still validate input and enforce authZ?
• Mistake: No replay protection on POST/PUT. Self-check: Do you use idempotency keys or nonces?
• Mistake: Logging sensitive data. Self-check: Are secrets, tokens, and PII redacted in logs?
• Mistake: Missing production validation. Self-check: Do you have rate limits, alerts, and trace IDs enabled?

Learning path

1. Start: Practice STRIDE on one existing endpoint.
2. Level up: Add risk scoring and map to backlog items.
3. Broaden: Include service-to-service calls, webhooks, and third-party APIs.
4. Automate: Codify checks in API specs and CI (linting for auth, rate limits, error models).
5. Operationalize: Add dashboards and alerts for abuse patterns.

Practical projects

• Project A: Threat model a small public REST API (users, orders). Deliver a 1-page model, top risks, and mitigation plan.
• Project B: Add query complexity limits to a GraphQL service and prove effectiveness with load tests.
• Project C: Implement webhook signature verification with replay protection and negative tests.

Mini challenge

You inherit a GET /reports?since=... endpoint that returns CSV files. Clients can request up to 90 days. Identify 3 threats and 3 mitigations in under 5 minutes.

Sample answer

• Threats: Data exfiltration via broad date range; DoS via large exports; IDOR via predictable file URLs.
• Mitigations: Require scoped tokens; cap date ranges and paginate; pre-signed URLs with short TTL and per-user checks; job queue and rate limits.

Next steps

• Apply the checklist to one real endpoint this week.
• Review your OpenAPI/GraphQL schema for fields that need authZ and add tests.
• Run the quick test below to lock in concepts.

Quick Test

Everyone can take the test. Sign in to save your progress and see it on your dashboard.