Skip to content

API and Microservices Threat Modeling: STRIDE, Trust Boundaries, and Header Propagation Security

Executive Summary

Microservices architectures replace monolithic applications with highly distributed networks of specialized services. This design improves scalability and agility but significantly increases the attack surface. In monolithic systems, security controls like user authentication are enforced once at the outer boundary. In contrast, microservices require continuous authorization checks at multiple internal boundaries. A common and dangerous mistake is assuming that internal networks are implicitly secure, leading teams to omit authentication checks between services.

At scale, the failure to secure the edge-to-internal transition and protect internal trust propagation headers creates major security holes. Attackers exploit these gaps by bypassing edge API Gateways and connecting directly to internal services, or by spoofing identity headers (e.g. X-Forwarded-User) to escalate privileges. This whitepaper explains how to threat-model microservices using the STRIDE framework, establish cryptographic trust boundaries, implement mutual TLS (mTLS), and secure user identity propagation.

Threat Model and Attack Surface

The microservices attack surface includes the outer ingress API Gateway, internal service-to-service communication paths, and backend data access points.

       [ Public Client Request ] -> [ API Gateway (Edge Auth) ]
                                          │
                  ( Gateways strips invalid user headers )
                                          │
                                          ▼
                      [ Internal Ingress: Service A ]
                                          │
                    ( Propagates user ID: X-User-Id )
                                          │
                                          ▼
                      [ Internal Target: Service B ]
                                          │
               ┌──────────────────────────┴──────────────────────────┐
               ▼ (Attack Path: Intercepted Service Mesh)             ▼ (Normal Authorized Path)
      [ Attacker Pod / Container ]                           [ Service B processes request ]
               │
               ▼
      [ Spoofs X-User-Id: admin ]
               │
               ▼
      [ Bypasses database constraints ]

Threat Vectors and Kill-Chains

  1. Identity Header Spoofing (Elevation of Privilege):
  2. Adversary Goal: Impersonate another user or acquire administrative access.
  3. Attack Vector: Internal services trust identity headers (e.g., X-User-Id or X-User-Roles) passed from upstream services without validation. An attacker compromises a frontend container. They bypass the API Gateway and send requests directly to the internal Billing service, attaching a custom header X-User-Id: admin-user. The Billing service processes the request without checking signatures, executing administrative tasks on behalf of the attacker.
  4. Gateway Bypass via Service Mesh Exposure:
  5. Adversary Goal: Bypass public-facing authentication checks.
  6. Attack Vector: An application is hosted in a Kubernetes cluster without network segmentation. While public traffic must route through the API Gateway (which enforces OAuth/JWT validation), internal ports of backend pods are left exposed. An attacker compromises an unsegmented staging pod and connects directly to a backend production service's internal port, bypassing all authentication gates.
  7. mTLS Cryptographic Identity Spoofing:
  8. Adversary Goal: Eavesdrop on or spoof service-to-service traffic.
  9. Attack Vector: Services communicate over plaintext HTTP inside the cluster, trusting IP addresses for authorization. An attacker deploys a malicious container in the same network namespace and performs ARP poisoning or DNS spoofing. This allows them to intercept and read sensitive traffic or masquerade as a trusted database server.

Deep Technical Body

The STRIDE Threat Modeling Methodology for Microservices

Threat modeling must be performed on every service integration using the STRIDE framework:

Threat Description Microservices Attack Vector Mitigation Strategy
Spoofing Pretending to be an authorized service or user. Spoofing DNS records to redirect service-to-service traffic. Enforce mutual TLS (mTLS) with strict SAN validation.
Tampering Modifying data in transit or at rest. Intercepting and altering plaintext HTTP calls inside the cluster. Encrypt all service communication in transit.
Repudiation Claiming actions were not taken. Incomplete logs that fail to correlate user IDs with internal API calls. Implement tracing headers (e.g. X-Request-ID) across all services.
Information Disclosure Exposing sensitive data. Reading unencrypted API responses or accessing trace details in logs. Enforce encryption in transit (mTLS) and dynamic logging policies.
Denial of Service Exhausting resources to block users. Flooding a single backend service to crash the entire application chain. Implement rate limiting, circuit breakers, and thread limits.
Elevation of Privilege Acquiring unauthorized access. Spoofing identity propagation headers to act as an administrator. Cryptographically sign user context tokens (e.g., nesting JWTs).

Trust Propagation Vulnerabilities and mitigations

A critical vulnerability in microservices is the insecure propagation of user context. When the API Gateway validates a user's OAuth access token, it must pass the user's identity to downstream services.

Insecure Pattern: Plaintext Headers

The gateway passes the user identity via a plaintext header: X-User-Id: 994218 This pattern is highly vulnerable. Any compromised service along the request chain can modify or spoof this header before forwarding the request to downstream services.

Secure Pattern: Signed Context Tokens (JSON Web Tokens)

Instead of plaintext headers, the gateway wraps the user identity in a short-lived, cryptographically signed JSON Web Token (JWT). Downstream services must validate the signature of this token before processing the request.

{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "gateway-signing-key"
}
...
{
  "sub": "994218",
  "roles": ["developer"],
  "exp": 1801234567,
  "iss": "internal-gateway"
}

Every backend service verifies the iss and the signature of this token using the gateway's public signing key, preventing internal header spoofing.

Defensive Architecture

A secure microservices architecture requires establishing cryptographic identities for all services and validating access rights at every internal boundary.

Reference Service Mesh Topology (Envoy Proxy / Istio)

[ Inbound HTTP ] -> [ Ingress Gateway ]
                          │
                  ( Establishes mTLS Tunnel )
                          │
                          ▼
            [ Service A Envoy Sidecar Proxy ]
                          │
               ( Enforces mTLS / JWT Auth )
                          │
                          ▼
            [ Service B Envoy Sidecar Proxy ]
  • mTLS (Mutual TLS): Envoy sidecar proxies manage all network traffic. Communication between proxies is encrypted using mutual TLS, validating the identity of both the client and server services.
  • Envoy AuthorizationPolicy: Enforce access controls at the sidecar proxy level. The policy below permits only the frontend service to invoke the /billing/checkout endpoint on the billing service:
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: billing-access-policy
  namespace: prod
spec:
  selector:
    matchLabels:
      app: billing
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/prod/sa/frontend-service-account"]
    to:
    - operation:
        methods: ["POST"]
        paths: ["/billing/checkout"]

Tooling and Implementation

Utilize service mesh and tracing infrastructure to automate security controls:

  1. Istio / Linkerd: Implement a service mesh to manage mutual TLS, traffic encryption, and authorization policies across all services without requiring code modifications.
  2. OpenTelemetry / Jaeger: Deploy distributed tracing to monitor requests as they traverse your services. Trace IDs allow security teams to audit the full path of a transaction, identifying anomalous routing patterns.
  3. SPIFFE/SPIRE: Use SPIFFE (Secure Production Identity Framework for Enterprise) to issue cryptographically signed, short-lived identities (SVIDs) to workloads automatically, facilitating secure service-to-service communication.

Microservices Threat Modeling Checklist

Item Focus Area Verification Step / Command Target State
1 Service Identity Verify if services use mutual TLS (mTLS) for all internal communication. Plaintext HTTP communication between service pods is disabled.
2 Ingress Controls Confirm if internal services accept traffic from outside the API Gateway. Network policies restrict ingress to the API Gateway or designated sidecars.
3 User Context Security Check how user identity is propagated between internal services. Identities are passed via signed internal JWTs, not plaintext headers.
4 Data Rate Limiting Audit rate limiting and circuit breaker configurations. Services limit request rates to prevent denial-of-service cascades.
5 Request Tracking Check if all microservice requests include tracing headers. Logs contain unique transaction trace IDs to facilitate security auditing.
6 Authorization Scope Verify if services validate access permissions locally. Services verify that the user identity has explicit authorization to perform the requested action.

References