Zero Trust API Design for Microservices

Identify each workload and each resource

Zero trust API design for microservices starts with a service inventory. List callers, target services, data classes, environments, and the exact actions each caller needs. A private subnet or shared cluster does not make a request trustworthy. Give each workload an identity that can be rotated and revoked independently. Record which service validates the identity and where a policy decision is enforced.

Draw the path of a real request, such as a checkout call that reaches payment, inventory, and notification services. Note where a user identity is preserved, where a workload identity is used, and where a new token is minted. A service should receive only the claims and permissions needed for its task. Passing a broad user token through every hop increases the damage possible from one compromised service.

Use transport protection and scoped authority

Mutual TLS can authenticate workloads and protect traffic in transit. It says which workload opened a connection, not which end user may read invoice 42. Apply resource and object authorization in the receiving service. Bind a token to its expected issuer, audience, expiry, and scope; reject tokens minted for another service. Avoid a single shared secret that grants every microservice the same capabilities.

Where a gateway exchanges a public token for an internal one, define the trust boundary and audit the mapping. Do not infer a user's role from unverified headers. If a service acts on behalf of a user, decide whether it may delegate the full action or only a narrow operation. Test token replay across services and environments. A staging token should never be accepted by a production audience.

Enforce policy at every hop

Central policy rules can improve consistency, but each service needs a reliable enforcement point before sensitive work. Verify that an internal route cannot be called directly with weaker checks than the public route. Add negative tests for another tenant, a revoked permission, and an unexpected method. Handle missing policy data by denying a sensitive action rather than quietly permitting it.

Be explicit about caching: a short-lived authorization cache improves latency but can leave revoked access active until expiry. Choose a time window appropriate to the action and record the trade-off. Recheck permissions on long-running jobs before releasing results. For asynchronous messages, authenticate producers and validate the intended consumer and tenant context; the trust boundary continues beyond HTTP.

Limit lateral movement

Network segmentation reduces reachable targets if a workload is compromised. Permit only required egress destinations and service ports, then measure denied connections to find accidental dependencies. Combine segmentation with narrow service identities and least-privilege database credentials. A network rule alone cannot stop a permitted service from calling an authorised endpoint with the wrong object ID.

Rotate service credentials and certificates on a tested schedule. Keep secrets out of container images, OpenAPI examples, and logs. Set an owner for each credential and make revocation possible without restarting unrelated services. During incident drills, revoke one workload and verify that its calls fail while healthy workloads continue. That test is more convincing than a policy diagram.

Use the contract to find review gaps

OpenAPI can document authentication requirements for each route and the expected error responses. Scan the document for operations with missing or inconsistent security declarations, then compare the intended policy with gateway and service configuration. APISAST can identify a missing declaration or certain sensitive unauthenticated write operations in a published contract. It cannot see mTLS handshakes, token validation code, or a service mesh policy.

Keep contracts for internal services in the inventory even if they are never publicly served. Mark the owner, environment, and allowed callers. Run a route comparison after deployment to catch services that expose an unexpected path. When a team deprecates a service, remove its identity, network permission, and credential together; a forgotten internal endpoint remains reachable long after its public client disappears.

Measure the right failure cases

Build tests around a valid request, a wrong audience, an expired credential, a caller from another service, and a cross-tenant object. Log enough context to explain a denied decision without recording raw tokens or personal data. Watch for sudden increases in denied calls, but investigate deployments and configuration drift before treating every denial as an attack.

Review policies whenever services split, merge, or introduce new asynchronous flows. A zero trust programme is a series of concrete access decisions and tests. The useful outcome is that one compromised workload has limited reach and every other service can still reject an unauthorised operation, even when the network path exists.

Example: a reporting service calls billing

Suppose a reporting worker requests billing data for a customer account. Its workload identity should permit a narrow read action for the reporting purpose, while the billing service still checks that the requested account matches the authorised job context. A compromised reporting worker must not become an administrator of billing. Include the job ID and tenant in a verifiable context rather than trusting caller-supplied headers.

Test the boundary with a valid job, a job from another tenant, a token issued for inventory, and a revoked reporting identity. Confirm that each denial is logged without copying invoice contents. If the worker queues results, protect the queue and output store under the same tenant boundary. This example shows why a service mesh connection and a valid token are useful but insufficient by themselves. Set a maximum for how long a report remains available. When account access is revoked, decide whether stored reports must be removed or rechecked at download time. This closes a gap between a secure read and an unprotected output.

Continue the work

Use these guides to put the checks into your API review process:

• Zero trust API design
• Public API access control
• Static API security tools

Primary reference: NIST SP 800-207 Zero Trust Architecture.

APISAST reviews OpenAPI and Swagger contracts for documented design signals. Confirm authorization, enforcement, performance, and abuse controls against a running service.