An API gateway is infrastructure that happens to enforce security, not a security product. Treating it as one is how teams end up with a hardened front door and an unlocked side entrance.
The short answer
An API gateway is a single entry point that sits in front of backend services. It routes requests, enforces authentication, applies rate limits, transforms payloads, manages versions and produces logs. It centralises concerns that would otherwise be duplicated in every service, which is a strong architectural reason to run one and a weak reason to consider your APIs protected.
The distinction matters because the gateway only sees traffic that goes through it, and it only checks the things it was told to check.
On this page
The six API gateway functions
| Function | What it does |
|---|---|
| Routing | Directs a request to the right backend service, hiding internal topology from clients |
| Authentication | Validates tokens, keys or certificates once, so each service does not reimplement it |
| Rate limiting and quotas | Caps request volume per client, protecting backends from overload and abuse |
| Transformation | Reshapes requests and responses between what clients send and what services expect |
| Versioning | Runs multiple API versions side by side so consumers migrate on their own schedule |
| Observability | Produces a consistent log and metric stream, which is what makes correlation possible later |
What an API gateway does to a request
What an API gateway does not catch
| Gap | Why the gateway misses it |
|---|---|
| Shadow and undocumented APIs | Endpoints deployed outside the API gateway are invisible to it, which is why external discovery keeps finding them |
| Broken object level authorisation | A valid token requesting someone else’s record looks like a legitimate request. Only the service knows it is not |
| Excessive data exposure | An endpoint returning more fields than the client needs passes through untouched |
| Business logic abuse | Sequences of individually permitted calls that add up to something the design never intended |
| Internal service traffic | Service to service calls that never traverse the gateway carry none of its policy |
| Schema drift | A new parameter shipped on Friday is not in the gateway’s definition until someone updates it |
Authentication is not authorisation
Nearly every serious API breach of recent years turns on this. The gateway confirmed a valid token, then a service returned data belonging to a different customer because the object level check was missing. Broken object level authorisation sits at the top of the OWASP API Security Top 10 precisely because it is invisible at the edge. A gateway cannot fix it, and a gateway vendor cannot claim to.
API gateway, WAF and API security
| API gateway | WAF | API security | |
|---|---|---|---|
| Primary job | Manage and route traffic | Block known attack patterns | Understand the API and how it is being used |
| Knows your endpoints | Only those registered with it | Only those behind it | Discovers them, including unregistered ones |
| Checks payload validity | Schema, if configured | Against attack signatures | Against learned normal behaviour |
| Catches logic abuse | No | Rarely | This is the point of it |
| You need it because | Architecture | Volume of generic attacks | The gaps the other two leave |
They stack rather than compete. Run an API gateway because managing routing, auth and rate limits in one place is good engineering. Add protection layers because the gateway was never designed to answer the question of whether a well-formed, authenticated request is legitimate.
How Osto approaches API gateway gaps
Osto is not an API gateway and does not replace one. Keep whichever you run. What Osto adds is the layer the gateway leaves uncovered.
Applications and APIs are discovered automatically, which matters most for endpoints that were never registered with a gateway in the first place. The engine learns URLs, parameters and HTTP methods for each application and generates a positive security policy from observed behaviour, so validation reflects what the API actually does rather than what a specification claims. Input validation, parameter type enforcement, cookie and session protection, file upload checks and protection against parameter pollution and forced browsing all apply to traffic the gateway would have passed on. Policy recommendations continue as the application changes, which addresses the schema drift row above. Requests correlate in the same SIEM as identity and endpoint events, so an unusual API call pattern can be read alongside the login that preceded it.
Platform walkthrough
Including the endpoints nobody registered
Automatic API discovery with a positive security policy generated from observed behaviour, not from a spec that drifted. Keep your gateway. One owner, one dashboard.
Book a demoAuto-discovery, auto-protection · No hand-written rules · One platform, everything
Frequently asked questions
What is an API gateway?
A single entry point in front of backend services that routes requests, enforces authentication, applies rate limits, transforms payloads, handles versioning and centralises logging. It removes the need for every service to implement those concerns separately.
Is an API gateway a security tool?
Partly. It enforces authentication and rate limiting, which are security functions, but it is designed as traffic infrastructure. It cannot see endpoints deployed outside it and cannot judge whether an authenticated request should be allowed to access a particular record.
What is the difference between an API gateway and a WAF?
A gateway manages and routes API traffic. A WAF inspects traffic for attack patterns and blocks them. They address different problems and are commonly deployed together, often with the WAF in front.
Do we still need API security if we have a gateway?
Yes. The most damaging API failures are broken object level authorisation, excessive data exposure and business logic abuse, none of which a gateway detects. Shadow endpoints outside the gateway are also a frequent finding.
Which API gateway should we use?
It is an architecture decision rather than a security one, driven by your cloud provider, traffic profile and how much routing logic you want to centralise. Whichever you choose, the coverage gaps described above are the same.