Securing APIs with Zero Trust Principles

The traditional approach to API security relied on a simple assumption: if a request came from inside the corporate network, it was probably safe. Firewalls guarded the perimeter, VPNs let remote workers in, and APIs on the internal network ran with minimal authentication. That assumption collapsed. The SolarWinds breach in December 2020 proved that attackers inside the network can abuse trusted API credentials for months without detection. Optus lost 9.8 million customer records through a single API that had no authentication at all because it was “internal.” This article covers how zero trust principles applied to APIs eliminate implicit trust, enforce verification on every request, and detect threats that traditional perimeter security misses entirely.

Why APIs Need Zero Trust More Than Any Other Component

APIs are the primary attack surface for modern applications. Unlike traditional web applications where a WAF could filter most threats at the HTTP layer, APIs expose structured endpoints that accept complex inputs, return sensitive data, and provide direct access to business logic. The OWASP API Security Top 10 (2023) documents attack patterns that are distinct from traditional web vulnerabilities: Broken Object Level Authorization, mass assignment, excessive data exposure, and unrestricted resource consumption are all API-specific threats that perimeter controls cannot address.

According to Salt Security’s 2023 report, 94% of organizations experienced an API security incident in the past 12 months. API attack traffic increased 400% year over year. The problem is not that organizations lack API security tools. The problem is that most API security still operates on implicit trust: if the token is valid, the request is allowed. Zero trust flips that model. Every request is suspect until proven otherwise, regardless of where it comes from or what credentials it carries.

The NIST SP 800-207 Zero Trust Architecture standard defines seven tenets. Three apply directly to API security: all communication is secured regardless of network location, access to resources is granted on a per-session basis, and all resource authentication and authorization are dynamic and strictly enforced before access is allowed. These are not abstract principles. They translate into specific technical controls that this article walks through with real implementations from Google, Netflix, and Cloudflare.

The Breaches That Proved Perimeter Security Fails for APIs

In December 2020, attackers compromised SolarWinds’ Orion build system and distributed a trojanized update to approximately 18,000 organizations. The malware, dubbed SUNBURST, used Orion’s legitimate API credentials and access tokens to communicate with management APIs across victim networks. Internal APIs trusted calls from the Orion platform because it was an authorized management tool on the internal network. The SUNBURST attack did not exploit an API vulnerability. It exploited the assumption that authorized software on a trusted network should be allowed to call internal APIs without further verification. CISA’s Emergency Directive 21-01 cited this as a fundamental failure of implicit trust.

T-Mobile’s January 2023 breach followed a similar pattern of misplaced trust. An attacker with valid API credentials extracted 37 million customer records over six weeks. The API worked exactly as designed. Authentication passed on every request. But no system questioned why a single caller was pulling millions of records at a pace that no legitimate use case would explain. Zero trust’s “assume breach” principle would have flagged this within hours, not weeks.

Peloton’s 2021 API vulnerability exposed 3 million user profiles because authorization was enforced only at the UI layer, not the API layer. An attacker could call the API directly, bypass the UI, and retrieve any user’s data by changing the user ID parameter. The API authenticated callers but never verified that the authenticated caller owned the requested resource. This is Broken Object Level Authorization, the number one vulnerability in the OWASP API Top 10, and it exists because the API implicitly trusted the client to send only its own user ID.

Zero Trust API Authentication: Short-Lived Tokens and Workload Identity

Zero trust rejects static API keys as a primary authentication mechanism. Static keys are equivalent to permanent passwords: they cannot be scoped per session, they do not expire without manual rotation, and their theft provides indefinite access. In March 2022, the Lapsus$ group breached Samsung’s source code repositories and found embedded API keys scattered across 190 GB of stolen code. Travis CI exposed authentication tokens for tens of thousands of open-source projects through an improperly secured API endpoint. Static keys are zero trust’s worst enemy.

The zero trust alternative is short-lived, scoped tokens issued through an OAuth 2.0 authorization server. For service-to-service API calls, the OAuth 2.0 Client Credentials grant with private_key_jwt client authentication eliminates shared secrets entirely. The calling service signs an assertion with its private key, and the authorization server verifies it against the registered public key.

 1{
 2  “access_token”: “eyJhbGciOiJSUzI1NiIsInR5cCI6ImF0K…”,
 3  “token_type”: “DPoP”,
 4  “expires_in”: 300,
 5  “scope”: “inventory:read orders:write”,
 6  “aud”: “https://api.company.com”,
 7  “cnf”: {
 8    “jkt”: “0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uf…”
 9  }
10}

The 300-second token lifetime ensures that even if the token is intercepted, the attacker’s window of access is five minutes. The aud claim binds the token to a specific API, preventing replay against other services. The cnf (confirmation) claim with a JWK thumbprint implements DPoP (RFC 9449, September 2023), which cryptographically binds the token to the caller’s private key. Even if the token is stolen, it cannot be used without the corresponding key.

SPIFFE/SPIRE for Workload Identity

For microservice architectures, SPIFFE (Secure Production Identity Framework for Everyone) provides cryptographic identity to every workload without relying on network location, environment variables, or static credentials. Each service receives a SPIFFE Verifiable Identity Document (SVID), an X.509 certificate with an identity like spiffe://company.com/payment-service. SVIDs are short-lived (typically one hour), automatically rotated by the SPIRE agent, and never touch disk in plaintext.

Uber uses SPIRE for service identity across thousands of microservices, as described at KubeCon 2019. Bloomberg, ByteDance, and Pinterest have also adopted SPIFFE for workload identity. SPIFFE eliminates the entire category of “leaked API credential” breaches because there are no long-lived credentials to leak. Every identity is cryptographic, short-lived, and automatically rotated.

The flow above shows how each API request passes through multiple verification stages before reaching the backend service. The authorization server issues short-lived, audience-bound tokens. The API gateway validates the token on every request. The application layer checks resource-level authorization. At no point does any component trust a request based on prior interactions.

Per-Request Token Validation

In a zero trust model, the API validates every aspect of the access token on every request. There is no “trusted session” that bypasses validation after the first call. The validation chain includes: verifying the cryptographic signature using the authorization server’s JWKS endpoint, checking the token has not expired, confirming the audience claim matches the API’s identifier, validating the issuer claim, and verifying the required scopes are present.

 1import jwt
 2from functools import lru_cache
 3
 4@lru_cache(maxsize=1)
 5def get_jwks():
 6    # Cache JWKS keys, refresh every 5 minutes
 7    resp = requests.get(“https://auth.company.com/.well-known/jwks.json”)
 8    return jwt.PyJWKClient(“https://auth.company.com/.well-known/jwks.json”)
 9
10def validate_token(token, required_scope):
11    jwks_client = get_jwks()
12    signing_key = jwks_client.get_signing_key_from_jwt(token)
13
14    payload = jwt.decode(
15        token,
16        signing_key.key,
17        algorithms=[“RS256″],
18        audience=”https://api.company.com”,
19        issuer=”https://auth.company.com”,
20        options={“require”: [“exp”, “iss”, “aud”, “scope”]}
21    )
22
23    # Verify required scope
24    granted = set(payload.get(“scope”, “”).split())
25    if required_scope not in granted:
26        raise PermissionError(f”Missing scope: {required_scope}”)
27
28    return payload

The options={"require": [...]} parameter ensures the token is rejected if any mandatory claim is missing. Without this, a token forged without an audience or issuer claim could pass validation. The JWKS client caches signing keys locally to avoid adding the authorization server as a latency bottleneck on every API call.

Microsoft took this further with Continuous Access Evaluation (CAE), introduced in Azure Entra ID in 2021. With CAE, API access tokens can be revoked mid-session based on real-time risk signals: the user’s location changed, the device fell out of compliance, or an administrator revoked access. Instead of waiting for the 5-minute token to expire, the API checks with the identity provider for real-time risk. This implements zero trust’s “never trust, always verify” principle at the session level, not just the authentication level.

Fine-Grained API Authorization at the Object Level

Authentication confirms the identity of the caller. Authorization determines what that identity can do. In zero trust, authorization must operate at the individual resource level, not just the endpoint level. The distinction is between “can this service call the /orders endpoint” and “can this service access order #12345 belonging to customer #67890.”

Google’s Zanzibar system, which powers authorization for Google Drive, YouTube, and Cloud IAM, introduced relationship-based access control (ReBAC). Open-source implementations like OpenFGA and SpiceDB bring this pattern to general-purpose APIs. Instead of checking “does this user have the admin role,” ReBAC checks “does this user have a viewer relationship to this specific document.”

 1model
 2  schema 1.1
 3
 4type user
 5
 6type organization
 7  relations
 8    define member: [user]
 9    define admin: [user]
10
11type order
12  relations
13    define org: [organization]
14    define viewer: member from org
15    define editor: admin from org
16    define creator: [user]

With this model, every API request to access an order triggers a relationship check. The API asks OpenFGA: “Does user service-account-X have a viewer relationship to order-12345?” The answer depends on whether that service account belongs to the same organization that owns the order. This is the core of zero trust authorization for APIs. The caller’s identity alone is not enough. The caller must have a verified relationship to the specific resource being requested, and that relationship is checked on every single request.

Mutual TLS and Service Mesh: Zero Trust Between APIs

When one microservice calls another, the calling service must prove its identity, and the receiving service must verify it. Mutual TLS (mTLS) provides this by requiring both sides of the connection to present valid certificates. Unlike standard TLS where only the server presents a certificate, mTLS ensures the client is also who it claims to be.

Google’s BeyondProd paper (December 2019) described how every service-to-service RPC at Google uses mutual TLS via their Application Layer Transport Security (ALTS) protocol. No service trusts another based on network location. Netflix implemented the same pattern across their 1,000+ microservices, combining their Zuul API gateway for edge authentication with mTLS for all internal service calls.

Service mesh platforms automate mTLS deployment. According to the CNCF 2023 Annual Survey, approximately 30-35% of organizations running Kubernetes have adopted a service mesh. Istio (the most widely adopted at 40% share) enables automatic mTLS with a single configuration.

 1apiVersion: security.istio.io/v1beta1
 2kind: PeerAuthentication
 3metadata:
 4  name: default
 5  namespace: production
 6spec:
 7  mtls:
 8    mode: STRICT
 9—
10apiVersion: security.istio.io/v1beta1
11kind: AuthorizationPolicy
12metadata:
13  name: order-service-policy
14  namespace: production
15spec:
16  selector:
17    matchLabels:
18      app: order-service
19  rules:
20  – from:
21    – source:
22        principals: [“cluster.local/ns/production/sa/payment-service”]
23    to:
24    – operation:
25        methods: [“GET”, “POST”]
26        paths: [“/api/v1/orders/*”]

The STRICT mode rejects any plaintext connection to services in the production namespace. The AuthorizationPolicy goes further: it restricts which service identities can call which endpoints. The payment-service can access order endpoints, but a logging service or analytics service cannot, even if they are in the same cluster. This is micro-segmentation applied to API traffic.

Linkerd takes a different approach with zero-config mTLS. Since Linkerd 2.0 (September 2018), every proxied connection between meshed services is automatically encrypted and mutually authenticated with no configuration required. Linkerd uses Rust-based micro-proxies with a smaller attack surface than Envoy-based proxies. Buoyant (Linkerd’s creator) reported that Linkerd processes over a trillion production requests per month across its user base.

The diagram above maps the enforcement layers that every API request must traverse in a zero trust architecture. Removing any single layer creates a gap. Without token validation, unauthenticated requests reach the backend. Without schema validation, malformed payloads trigger unexpected behavior. Without object-level authorization, authenticated callers access resources they do not own.

API Gateway as the Zero Trust Enforcement Point

An API gateway serves as the policy enforcement point where all zero trust controls converge. Over 90% of organizations with API programs use some form of gateway (Gartner). The gateway validates tokens, enforces rate limits, validates request schemas, and logs every transaction before the request reaches the backend service.

Cloudflare launched API Shield in October 2020, providing mTLS-based API authentication where each IoT device or API client gets a unique client certificate. Cloudflare validates certificates on every request, protecting billions of API calls per day. In 2023, they added sequence detection, which blocks API calls that arrive out of the expected order, addressing business logic abuse that token validation alone cannot catch.

 1# Headers every zero trust API gateway should enforce
 2Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
 3X-Content-Type-Options: nosniff
 4X-Frame-Options: DENY
 5Cache-Control: no-store
 6X-Request-ID: f47ac10b-58cc-4372-a567-0e02b2c3d479
 7X-Authenticated-User: service:payment-processor
 8X-Authorization-Decision: ALLOW
 9X-Rate-Limit-Remaining: 87
10X-Rate-Limit-Reset: 1713234567

The X-Authenticated-User and X-Authorization-Decision headers propagate the gateway’s security decisions to backend services. This enables defense in depth: even if an attacker bypasses the gateway, the backend service can independently verify these headers against its own authorization logic.

Continuous Monitoring: The “Assume Breach” Principle

Zero trust’s third principle, “assume breach,” means that even after a request passes authentication and authorization, the system must continuously monitor for signs that something is wrong. T-Mobile’s breach lasted six weeks because no monitoring system flagged 37 million records being extracted through a single API. The API was functioning correctly. Authentication was passing. Authorization was valid. But the volume of data extraction was orders of magnitude beyond any legitimate pattern.

Behavioral analysis of API traffic must establish baselines for each authenticated identity: typical request volumes, accessed endpoints, request timing patterns, and data volumes. When a service account that normally makes 100 inventory reads per hour suddenly begins making 10,000 reads per minute, that anomaly must trigger an automated response regardless of whether each individual request is properly authenticated.

 1import structlog
 2from datetime import datetime, timedelta
 3
 4logger = structlog.get_logger()
 5
 6def check_api_anomaly(caller_id, endpoint, window_minutes=60):
 7    # Get baseline from last 7 days
 8    baseline = get_request_baseline(caller_id, endpoint, days=7)
 9    current = get_request_count(caller_id, endpoint, minutes=window_minutes)
10
11    ratio = current / max(baseline.avg_per_hour, 1)
12
13    if ratio > 10:
14        logger.warning(“api_anomaly_critical”,
15            caller=caller_id, endpoint=endpoint,
16            current=current, baseline=baseline.avg_per_hour,
17            ratio=round(ratio, 1))
18        suspend_caller(caller_id, reason=”volume_anomaly”)
19        return “BLOCKED”
20
21    if ratio > 5:
22        logger.warning(“api_anomaly_elevated”,
23            caller=caller_id, endpoint=endpoint,
24            current=current, baseline=baseline.avg_per_hour)
25        require_step_up_auth(caller_id)
26        return “STEP_UP”
27
28    return “ALLOW”

This graduated response model matches the zero trust principle of continuous evaluation. A 5x spike triggers step-up authentication (maybe re-verify the caller’s identity with a fresh token). A 10x spike suspends the caller entirely. The IBM Cost of a Data Breach Report 2023 found that organizations with mature zero trust deployments had an average breach cost of $3.28 million, compared to $5.04 million without zero trust. That $1.76 million difference comes primarily from faster detection and containment, which continuous monitoring provides.

API Versioning and the Shadow API Problem

Deprecated API versions often lack the latest security controls, creating a bypass path for attackers. If v2 of your API enforces object-level authorization but v1 only checks endpoint-level permissions, an attacker who discovers v1 is still running can bypass the stricter controls entirely. Gartner predicted that by 2025, less than 50% of enterprise APIs would be managed. The rest are shadow APIs: undocumented, unmonitored endpoints running in production.

The CISA Zero Trust Maturity Model v2.0 (April 2023) addresses this directly. At the “Optimal” maturity level, organizations must maintain continuous API discovery and automated inventory. Every API endpoint in production should be registered in the gateway and included in security scans. When you deprecate a version, shut it down. Do not leave it running because “some old client might still use it.”

A zero trust approach to API versioning mandates that security policies are applied uniformly across all supported versions. When a new version introduces stricter checks, the old version must either be upgraded to match or decommissioned. Maintaining two versions with different security postures violates the core zero trust principle that every access request must be fully verified.

How Google, Netflix, and Cloudflare Implement Zero Trust APIs

Google BeyondProd. Published in December 2019, BeyondProd extends BeyondCorp to service-to-service communication. Every RPC at Google uses mTLS via ALTS (Application Layer Transport Security). Every microservice gets a cryptographic identity. API calls carry end-user context through the entire call chain via “End User Context Tickets,” so authorization decisions happen at every hop, not just at the edge. Before any code can serve API traffic, it must pass Binary Authorization, proving it was built from reviewed, checked-in code through Google’s official pipeline.

Netflix. Netflix runs over 1,000 microservices. Their Zuul API gateway handles edge authentication and token validation for every external API request. Internal service calls use mTLS. Their “Paved Road” initiative provides pre-built secure service templates with built-in authentication, authorization, and encryption. Developers who follow the paved path automatically get zero trust controls. Bryan Zimmer described Netflix’s continuous access evaluation at USENIX Enigma 2019: device posture and user risk signals are evaluated on every API call to internal tools, not just at login.

Cloudflare API Shield. Launched in October 2020, API Shield provides mTLS authentication where each client gets a unique certificate. Every API request is validated against an uploaded OpenAPI schema, rejecting malformed or unexpected requests at the edge. In 2023, Cloudflare added API sequence detection, enforcing that API calls arrive in the expected order. This catches business logic abuse that token validation alone cannot detect.

What these three implementations share is a rejection of implicit trust at every layer. Network location does not grant access. Valid credentials do not bypass authorization. Passing authentication does not exempt a request from monitoring. These are not theoretical principles. They are production architectures serving billions of API calls per day.

The Zero Trust API Maturity Path

The CISA Zero Trust Maturity Model defines four levels for the Applications and Workloads pillar. Mapping these to API security gives organizations a concrete path forward:

• Traditional. Static API keys, basic authentication, no API gateway. Rate limiting by IP address. No API inventory. This is where most organizations start, and where Optus was when they lost 9.8 million records
• Initial. OAuth 2.0 token-based authentication, basic API gateway with token validation, per-consumer rate limits. API endpoints documented but not continuously discovered
• Advanced. Short-lived tokens with DPoP binding, mTLS between services, relationship-based authorization (ReBAC), automated schema validation, API anomaly detection with behavioral baselines
• Optimal. SPIFFE/SPIRE workload identity, continuous access evaluation, real-time risk-based access decisions, automated API discovery and inventory, binary authorization for API-serving workloads. This is where Google BeyondProd operates

Forrester’s Total Economic Impact study (commissioned by Microsoft, 2021) found that organizations implementing zero trust achieved a 92% ROI over three years, a 50% reduction in breach risk, and 50% faster threat response time. The investment is front-loaded in tooling and architecture changes, but the payoff compounds as each control reinforces the others.

References

• NIST, SP 800-207: Zero Trust Architecture, August 2020
• CISA, Zero Trust Maturity Model v2.0, April 2023
• Google Cloud, BeyondProd: A New Approach to Cloud-Native Security, December 2019
• OWASP, API Security Top 10 (2023 Edition), June 2023
• IBM Security, Cost of a Data Breach Report 2023, July 2023
• Salt Security, State of API Security Report Q1 2023, 2023
• IETF, RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP), September 2023
• SPIFFE, Secure Production Identity Framework for Everyone, CNCF Graduated Project
• Cloudflare, Introducing API Shield, October 2020
• Forrester, The Total Economic Impact of Zero Trust Solutions, December 2021

Frequently Asked Questions