API gateways enforce identity, validate requests, and inspect traffic at the entry point to API ecosystems. In Zero Trust deployments, they replace network-location trust with identity-based authorisation evaluated per request. The OWASP API Security Top 10 (2023) defines the risk taxonomy. Modern SASE platforms deliver many gateway functions through their ZTNA, WAF, and SWG components for north-south traffic.
APIs have become the dominant interface between services in 2026. A typical mid-market organisation exposes dozens of public APIs and orchestrates hundreds of internal ones. The traditional firewall does not understand API semantics. It checks IP addresses and ports, not whether a signed token grants the caller permission to read account 4471 rather than account 4470. The API gateway became the control point that does understand those semantics, but only when paired with identity-based access and continuous evaluation. This post treats the gateway as a senior IT lead or platform engineer would when placing it inside a Zero Trust architecture. For the conceptual groundwork, our explainer on API security fundamentals covers the basics this post assumes.
What an API gateway does in a Zero Trust architecture
An API gateway is a reverse proxy that routes API calls, enforces authentication, validates requests, applies rate limits, and logs every transaction. In a Zero Trust model it acts as the Policy Enforcement Point, verifying identity and entitlement per request rather than per session. NIST SP 800-207 describes this resource-level enforcement: access decisions are made for each individual resource, not granted once at the network boundary.
The gateway decouples backend logic from traffic management, credential validation, and protocol translation. It sits where external clients meet internal services, and that border has a direction. North-south traffic enters the cluster from external clients: single-page applications, mobile apps, third-party partners. The gateway terminates those connections, validates external tokens, enforces client rate limits, and scrubs payloads. East-west traffic is service-to-service communication inside the cluster, which a service mesh handles more efficiently than a central gateway. The two patterns complement each other.
Common implementations include Kong, AWS API Gateway, Azure API Management, Apigee, and Cloudflare API Shield, each differing in protocol support and policy depth. In Kubernetes, the Gateway API succeeded the older Ingress API, splitting responsibilities into distinct resources so security teams can enforce global policies like mTLS or Web Application Firewall bindings while developers define routing within their namespaces.
The OWASP API Security Top 10 (2023) and what your gateway must address
The OWASP API Security Top 10 (2023 edition) is the current authoritative list of the most critical API vulnerabilities. It replaced the 2019 edition and merged several categories, notably folding excessive data exposure and mass assignment into a single risk. A gateway configured as a positive security layer mitigates most of these, but not all, and the gaps are where downstream services and broader Zero Trust controls take over.
| OWASP ID | Risk name | Gateway capability needed | Compensating control where gateway falls short |
|---|---|---|---|
| API1:2023 | Broken Object Level Authorization (BOLA) | Extract user identity from signed token, compare against object ID in path or body | Tenant-group checks against live database state must run in downstream services |
| API2:2023 | Broken Authentication | Centralised JWT signature, expiry and audience validation; OIDC integration | Cannot fix weak password hashing or compromised credentials on the identity server |
| API3:2023 | Broken Object Property Level Authorization | Strict OpenAPI schema validation; scrub undocumented fields inbound and outbound | Cannot judge whether a user has a legitimate business reason to view a declared property |
| API4:2023 | Unrestricted Resource Consumption | Rate limiting, payload size limits, execution timeouts | Cannot stop resource exhaustion inside the gateway process during large DDoS floods |
| API5:2023 | Broken Function Level Authorization (BFLA) | RBAC and scope validation at the routing layer per HTTP path and verb | Wildcard-routed or unmapped admin endpoints may escape policy |
| API6:2023 | Unrestricted Access to Sensitive Business Flows | Bot mitigation, anomaly detection, IP reputation, sequence rate limiting | Human-like automated flows mimicking legitimate sequences may bypass edge models |
| API7:2023 | Server Side Request Forgery (SSRF) | Destination allowlisting on outbound traffic; sanitise user-supplied URIs | Cannot block SSRF where backends use direct outbound paths bypassing the proxy |
| API8:2023 | Security Misconfiguration | Enforce security headers and CORS policy; rewrite verbose error payloads | Cannot fix misconfigurations inside internal service-to-service networks |
| API9:2023 | Improper Inventory Management | Runtime API discovery, automatic schema generation, traffic auditing | Discovery needs active traffic; dark, unvisited routes stay undetected |
| API10:2023 | Unsafe Consumption of APIs | Egress gateways validating outbound structures and third-party response schemas | Backends configured to bypass egress gateways admit untrusted payloads unvalidated |
The pattern is consistent. The gateway handles structural and identity enforcement well. It struggles wherever a decision depends on live business context or on traffic that never passes through it.
Authentication patterns: OAuth 2.1, JWT, mTLS and the API key reality
Four authentication patterns dominate in 2026. OAuth 2.1 consolidates a decade of security lessons into a single prescriptive framework. JWT carries stateless identity claims. mTLS handles service-to-service trust. API keys persist for low-risk, read-only scenarios. Each fits a different threat model, and choosing the wrong one is a common source of weakness.
OAuth 2.1 (draft-ietf-oauth-v2-1) is not a new protocol. It removes insecure defaults from OAuth 2.0. PKCE, previously recommended only for public clients, becomes mandatory for every client using the Authorization Code Flow, closing the authorization code interception attack on the redirect URI. The Implicit Grant and Resource Owner Password Credentials grant are both removed, because the first leaks tokens into browser history and the second forces apps to handle raw credentials.
JWT (RFC 7519) is a self-contained token whose convenience is also its weakness, because verification logic often trusts properties inside the token itself. Two attacks recur. The alg: none exploit strips the signature when a parsing library honours an unsigned algorithm header. The algorithm confusion attack swaps an asymmetric RS256 token for a symmetric HS256 one, signing the forgery with the target’s public key. The mitigation for both: the gateway must ignore the token’s algorithm header and enforce a static whitelist, validating signatures against keys retrieved out-of-band via JWKS.
mTLS suits high-trust east-west traffic and machine-to-machine communication. Both parties present X.509 certificates, and the private key never leaves the client, which eliminates token extraction and replay. The cost is PKI management, which makes it a poor fit for user-facing browser apps where a JWT carries identity better. Our deep-dive on mutual TLS for service-to-service authentication covers the certificate mechanics. API keys remain useful but constrained. They are static secrets with no expiry, no native multi-factor support, and a habit of leaking into public repositories. Fine for public developer portals and read-only content APIs, inappropriate for sensitive business APIs. The API token mechanics behind these patterns are worth understanding before you choose.
One pattern ties these together. Traditional OAuth tokens suffer from an active-session window: once authorised, a token works until expiry, even if the account is disabled in the interim. The Continuous Access Evaluation Profile, built on the Shared Signals Framework, resolves this. The identity provider streams Security Event Tokens (RFC 8417) to the gateway. When a user is terminated or a device fails compliance, the gateway invalidates the token immediately and the next request gets a 401 with a claims challenge. This lets gateways use longer-lived tokens safely, because security comes from real-time signals rather than short expiry timers.
Schema validation, rate limiting and the request inspection layer
API gateways do far more than authenticate. They enforce a positive security model by validating every request against an OpenAPI Specification 3.1 contract, apply rate limits to prevent abuse, and enforce constraints like body size to block injection and exhaustion attacks. Inspection at the edge keeps malformed payloads away from backend code entirely.
Schema validation is the workhorse. OAS 3.1 defines exact paths, parameters, headers, and payload structures. When an attacker injects an undocumented field, say "user_role": "admin" in a profile update, the gateway sees a field absent from the schema and rejects the payload, mitigating the mass-assignment side of API3:2023. It also prevents malformed input from triggering parser crashes that leak stack traces.
Rate limiting protects availability across several dimensions: per-client using OAuth client IDs, per-IP for unauthenticated traffic, or per-endpoint to throttle heavy routes harder. The algorithm matters. Token bucket allows controlled bursts while holding a steady average. Leaky bucket smooths output completely by queueing at a fixed release rate, at the cost of latency. Sliding window log records each timestamp and prunes old entries, eliminating the boundary-burst flaw of fixed windows where an attacker doubles their quota by firing requests either side of a reset. In multi-region deployments, gateways pre-allocate a block of tokens from a central Redis cache locally to avoid a network round-trip per request.
Schema validation cannot catch behavioural abuse. Credential stuffing and scraping look structurally valid. Modern gateways add bot management that profiles client fingerprints, headless browser signatures, and login sequence patterns, integrating engines such as Cloudflare API Shield or Akamai API Security to block automated abuse that passes every syntactic check.
REST, GraphQL and gRPC: protocol-specific inspection challenges
Protocol shapes inspection. REST is the simplest case: the gateway matches URI paths, parses headers, and validates verbs. GraphQL and gRPC each break that model differently, and a gateway that handles one well may handle another poorly. Organisations running multiple protocols should verify capability per protocol rather than assuming uniform coverage.
GraphQL uses a single endpoint with custom nested queries, so path-based filtering and request counting are useless. The gateway must parse each query into an Abstract Syntax Tree inline, then limit nesting depth to block recursive queries that starve CPU, score query complexity, and validate variables against the schema before forwarding. This AST traversal is why GraphQL inspection carries higher overhead than REST.
gRPC runs on HTTP/2 with binary Protobuf serialisation. Because payloads are binary and multiplexed over one connection, traditional L4 load balancing causes backend hot-spotting. Gateways need HTTP/2 frame inspection and compiled Protobuf descriptor sets to transcode between JSON and gRPC. The security vectors differ too: REST sees injection and parameter tampering, GraphQL sees denial of service through recursive nesting, gRPC sees cascading failures from missing RPC deadlines.
East-west API traffic and the service mesh complement
North-south traffic is the gateway’s domain. East-west traffic, service to service inside the infrastructure, is increasingly handled by a service mesh such as Istio, Linkerd, or Consul Connect. These complement rather than compete, and conflating them produces either gaps or needless complexity.
Service meshes enforce identity locally rather than routing internal calls back through a central edge. They establish workload identity through SPIFFE/SPIRE, which issues short-lived X.509 certificates (SVIDs) after the SPIRE agent validates characteristics like Kubernetes pod ID and container digest. Envoy sidecar proxies use these SVIDs to run mTLS handshakes and enforce workload-to-workload policy. Node-level approaches using eBPF, such as Cilium Ambient Mesh, reduce sidecar overhead.
NIST SP 800-207 applies the same tenet to both directions: access to each resource is verified dynamically and never granted implicitly. For mid-market teams, the practical advice is restraint. A full service mesh is often overkill when a single gateway already enforces identity at the edge and internal service count is modest. Add the mesh when east-west authorisation genuinely needs per-call cryptographic identity, not before.
Where SASE platforms integrate API gateway functions
Single-vendor SASE platforms consolidate gateway functions into one control plane rather than running them as an isolated silo. ZTNA acts as the north-south enforcement point, authenticating users on identity and device posture before any API connection. SWG inspects outbound API calls to external services. FWaaS provides L4 to L7 policy at the edge. WAF protects endpoints from OWASP risks. Centralised logging produces the audit trail that NIS2 and CyFun require.
One distinction is worth stating plainly. A WAF and an API gateway are complementary layers, not substitutes. The WAF works on a negative model, matching signatures to block known attacks like SQL injection, XSS, and volumetric floods. The API gateway works on a positive model, permitting only what schemas and identity claims define. In a robust design the WAF shields the gateway from raw exploits and DDoS, while the gateway handles granular identity, routing, and schema conformity. Vendors split on QUIC handling: some inspect it inline, others block UDP/443 to force a TCP fallback, a split we covered in our analysis of TLS 1.3 and QUIC inspection.
When evaluating an architecture like the Jimber SASE platform, these functions arrive as part of a converged edge fabric. Zero Trust Network Access authenticates users on real-time posture before connecting them to API endpoints. The Secure Web Gateway inspects outbound requests to external SaaS to prevent data exfiltration. The edge WAF and Firewall-as-a-Service filter common OWASP exploits at the branch and cloud edge.
Be honest about the boundary. Jimber is not a dedicated API gateway product. It delivers many gateway functions through component integration, which suits mid-market organisations that want consolidation over a separate specialised tool. An organisation needing a full developer portal, API monetisation, or fine-grained per-endpoint transformation will likely run a dedicated gateway like Kong or Apigee inside its clusters alongside the SASE platform. The two are not mutually exclusive.
Real-world API breaches a properly configured gateway would have prevented
Named breaches from 2022 to 2025 show what weak gateway controls cost. Optus and T-Mobile both exposed tens of millions of records through API failures that schema validation and edge authentication would have stopped. Research from Salt Security indicates the problem is systemic, and that the attack surface has shifted inside the authenticated perimeter.
The Optus breach (September 2022) exposed data for roughly 9.8 million current and former customers. The cause was an unauthenticated API endpoint on a dormant subdomain connected to a production database, with access controls left inactive by a 2018 coding error. The endpoint used predictable identifiers, so an attacker scripted a loop to scrape records sequentially, a textbook BOLA (API1:2023) failure. The Office of the Australian Information Commissioner pursued the matter under the Privacy Act 1988.
The T-Mobile breach (January 2023), disclosed in an SEC filing, saw an attacker abuse a vulnerable API endpoint to harvest data on around 37 million accounts without triggering system errors, combining weak input validation and broken authorisation. In September 2024 T-Mobile settled with the US Federal Communications Commission, paying a 15.75 million USD penalty and committing an equal sum to implement Zero Trust architecture, strict identity controls, and a critical asset inventory. The remedy the regulator mandated is, in effect, the gateway and Zero Trust controls described throughout this post.
The 2025 Salt Security State of API Security report puts these in context. Nearly all surveyed organisations encountered an API security problem in the past year. Two findings stand out. The great majority of observed attack attempts came from authenticated sources, because attackers obtain valid accounts or compromise credentials, which shifts the requirement from authentication-at-the-gate to continuous runtime evaluation. And undocumented shadow and zombie APIs make up a substantial share of the active footprint, with only a small minority of organisations confident in their inventory. These figures are vendor-published and based on analysed customer traffic, so treat the exact percentages as directional. The architectural lesson holds: continuous discovery and runtime behavioural analysis matter as much as the initial token check.
Frequently asked questions
What is the difference between an API gateway and a WAF?
A WAF uses a negative security model, blocking known attack signatures like SQL injection and XSS. An API gateway uses a positive model, permitting only what schemas and identity claims define and rejecting the rest. They work as complementary layers, with the WAF in front of the gateway.
Does OAuth 2.1 replace OAuth 2.0 in 2026?
OAuth 2.1 consolidates OAuth 2.0 rather than replacing the protocol. It mandates PKCE for all clients, removes the Implicit and Resource Owner Password Credentials grants, and requires refresh token rotation. The specification remains a draft, but major identity providers already enforce its defaults in production.
Can a SASE platform replace a dedicated API gateway?
For many mid-market needs, yes. A SASE platform delivers identity-based access, schema-aware inspection, WAF protection, and logging through integrated components. Organisations needing a developer portal, API monetisation, or advanced per-endpoint transformation usually run a dedicated gateway alongside the SASE platform rather than instead of it.
How does an API gateway handle GraphQL differently from REST?
REST inspection matches paths, headers, and HTTP verbs. GraphQL uses one endpoint with nested queries, so the gateway parses each query into an Abstract Syntax Tree, limits nesting depth, scores query complexity, and validates variables before forwarding. This makes GraphQL inspection more resource-intensive than REST.
What is the most common OWASP API risk in mid-market deployments?
Broken Object Level Authorization (API1:2023) is the most frequently exploited. It occurs when an API fails to check that the authenticated user owns the object they request, letting attackers iterate through object identifiers to access other users’ records. Both the Optus and T-Mobile breaches involved this pattern.
Should API gateway authentication use JWT or session tokens?
JWTs suit distributed, stateless architectures because services validate them without calling back to the identity provider. The trade-off is revocation: a stateless token stays valid until expiry. Pairing JWTs with Continuous Access Evaluation signals resolves this by pushing real-time revocation events to the gateway.
How does API gateway security integrate with Zero Trust architecture?
The gateway acts as the Policy Enforcement Point defined in NIST SP 800-207. It verifies identity and entitlement per request, queries a Policy Decision Point for each transaction, and enforces least-privilege access continuously through CAEP signals rather than granting trust once at the network boundary.
The API gateway in 2026 is the identity enforcement point for API-driven architecture. The OWASP API Security Top 10 (2023) defines what it must address, and the mapping table shows exactly where it succeeds and where downstream services take over. What determines whether API exposure stays a controlled risk or becomes the breach path is the combination: identity validation, schema enforcement, continuous evaluation, and the Zero Trust controls around them. Consolidating those controls into one platform removes the seams where gaps appear. To see how Jimber brings ZTNA, WAF, FWaaS, and centralised logging together for API exposure across a mid-market estate, book a demo and walk through your own architecture with the team.
