An API gateway is the single chokepoint that sits between every client and a backend's collection of services, handling routing, authentication, and rate limiting for every request that passes through it. That makes it one of the highest-leverage pieces of infrastructure a security team can get right — or catastrophically wrong. When T-Mobile disclosed in January 2023 that an attacker had pulled data on 37 million accounts starting November 25, 2022, the entry point was a single exposed API, not a phished credential or a zero-day in an operating system. Optus lost records on 9.8 million customers in September 2022 the same way: an internet-facing API that didn't require authentication. Gartner had already flagged this shift in 2021, predicting API abuses would become the most frequent attack vector for enterprise web applications. This glossary post explains what an API gateway actually does, where it fails, and how to configure one so it earns its place as a security control rather than just a routing layer.
What is an API gateway?
An API gateway is a reverse proxy that sits in front of a set of backend services and centralizes cross-cutting concerns — routing, authentication, rate limiting, request/response transformation, and logging — so individual services don't each have to implement them. Instead of a mobile app calling orders-service, inventory-service, and pricing-service directly on three different hosts, it calls one gateway endpoint, and the gateway routes /v1/orders to the orders service and /v1/inventory to the inventory service based on path, header, or hostname rules. Products like Kong Gateway, AWS API Gateway, Apigee, and Envoy-based gateways such as Istio's ingress gateway all do this same job, differing mainly in deployment model (self-hosted vs. managed) and plugin ecosystem. Kong alone reports over 300,000 downloads per month of its OSS gateway as of 2025, an indicator of how load-bearing this layer has become in modern architectures. Because every request from the outside world passes through it, the gateway is also the natural place to enforce security policy consistently rather than duplicating auth logic across dozens of microservices.
Why does an API gateway matter for security, not just routing?
An API gateway matters for security because it is the one place where you can enforce authentication, authorization, and abuse controls before a request ever reaches business logic that may not validate them itself. In a microservices architecture with 50 or 100 internal services, expecting every team to correctly implement JWT validation, mutual TLS, and rate limiting independently is unrealistic — Salt Security's State of API Security report for the first half of 2022 found a 400% increase in unique attackers targeting customer APIs over the prior six months, much of it low-and-slow credential stuffing and enumeration that a properly configured gateway would throttle before it reached an application. A gateway that terminates TLS, validates tokens against an identity provider, and applies per-client rate limits (a common baseline is 100 requests per minute per API key) turns "every service must defend itself" into "one control point defends everything behind it." The tradeoff is concentration of risk: misconfigure the gateway and every service behind it inherits the exposure at once, which is exactly what happened at Optus and T-Mobile.
What are the biggest API gateway security risks?
The biggest risks are misconfigured authorization and unauthenticated exposure, which is why the OWASP API Security Top 10 (2023 edition) puts Broken Object Level Authorization at API1 and Broken Authentication at API2. Broken Object Level Authorization happens when a gateway or the service behind it checks that a caller is authenticated but never checks that the specific object being requested belongs to that caller — an attacker who is logged in as user 1001 simply changes /v1/orders/1001 to /v1/orders/1002 in the URL and retrieves someone else's order. Peloton hit this exact bug in January 2021: its API let any authenticated user query the profile data of any other user by ID, exposing age, weight, gender, and location data for roughly 3 million riders, including a subset of accounts marked private, before Pen Test Partners disclosed it. Coinbase paid a $250,000 bug bounty in 2022 for a related class of flaw — an API-level logic error that would have let an attacker sell crypto they didn't own. Rate-limiting gaps are the second recurring theme: a gateway that authenticates correctly but applies no throttling per client or per endpoint leaves credential-stuffing and enumeration attacks running at whatever speed the attacker's infrastructure supports.
How does an API gateway differ from a WAF or a service mesh sidecar?
An API gateway, a WAF, and a service mesh sidecar operate at different layers and solve different problems, even though vendors increasingly bundle all three. A WAF inspects HTTP traffic for known attack signatures — SQL injection strings, XSS payloads, path traversal patterns — and is typically deployed at the network edge in front of the gateway; it doesn't understand your API's object model or who owns which resource, so it can't stop Broken Object Level Authorization. A service mesh sidecar, like an Envoy proxy injected via Istio or Linkerd, handles east-west traffic between internal services — mutual TLS, retries, circuit breaking — and generally isn't the first thing an external client talks to. The API gateway sits between the two: it's the north-south entry point that understands API-specific semantics (paths, methods, schemas, API keys, OAuth scopes) well enough to enforce authorization decisions, while a WAF and a mesh handle the broader traffic-shape and network-layer concerns around it. Treating any one of the three as sufficient on its own is how gaps like the ones above get through.
What are real-world examples of API gateway security failures?
The clearest examples are the T-Mobile, Optus, and F5 BIG-IP incidents, each of which shows a different failure mode. T-Mobile's November 2022 breach traced back to a single API that an attacker abused starting around November 25, 2022, and used to pull name, billing address, email, phone number, date of birth, and account number for 37 million current customers before detection on January 5, 2023 — T-Mobile's eighth publicly disclosed breach since 2018. Optus's September 2022 breach exposed government ID numbers, addresses, and dates of birth for 9.8 million customers through an API endpoint left reachable from the internet without authentication, reportedly reachable via a predictable, non-production test URL. On the infrastructure side, F5 disclosed CVE-2023-46747 in October 2023, an authentication bypass in the BIG-IP Configuration utility carrying a CVSS score of 9.8 that let an unauthenticated attacker with network access to the management interface execute arbitrary system commands — a reminder that the gateway's own management plane is as much a target as the APIs it fronts. None of these required a novel exploitation technique; each was a gap in authentication or authorization enforcement at the one layer meant to catch it.
What does a secure API gateway configuration look like?
A secure API gateway configuration enforces authentication and object-level authorization on every route, applies per-client rate limits, validates request schemas, and logs every request with enough detail to reconstruct an incident. Concretely: every route should require a valid OAuth 2.0 token or signed API key rather than relying on an "internal network" assumption, since Optus and T-Mobile both show that assumption fails; authorization checks need to validate that the token's subject actually owns or has been granted the specific resource ID in the path, not just that the token is valid; rate limits should be set per API key and per endpoint (burst limits around 10-20 requests per second are typical for consumer-facing endpoints, with lower ceilings on expensive endpoints like search or export); and request bodies should be validated against an OpenAPI schema so malformed or oversized payloads are rejected at the gateway instead of reaching application code. Gateway software itself needs the same patch discipline as any other internet-facing service — Kong, Apigee, and BIG-IP have all shipped CVE fixes in the past two years, and a gateway running a version with a known authentication bypass negates every policy configured on top of it.
How Safeguard Helps
Safeguard extends this same discipline to the software that runs your API gateways and the services behind them. Our reachability analysis maps which gateway plugins, SDKs, and backend dependencies are actually invoked by live request paths, cutting 60-80% of CVE noise so a finding like CVE-2023-46747 in a BIG-IP or Kong deployment gets triaged by actual exposure instead of CVSS score alone. SBOM generation and ingestion covers the gateway's own container images and plugin dependencies, giving you a verifiable inventory of what's running at your single point of ingress rather than a guess. Griffin AI correlates gateway configuration drift and vulnerable dependency versions against your live traffic graph, and when a fix is available, Griffin opens an auto-fix pull request against the exact manifest or config file that needs the version bump — turning a CVE advisory into a reviewable diff instead of a ticket that sits in a backlog while your gateway stays exposed.