Why Api Gateways Are Dead (1 of 2)

6 min readNov 2, 2022

(continue to Why Api Gateways are Dead Part 2 )

Are you aware that recently a report came out saying that 92% of all orgs experienced an API security incident in the last year?

Are you ALSO aware that the same top companies who were seeing sales drop in Enterprise Service Buses (ESB) are the same exact same companies who want to sell you on the concept of the API Gateway?

Why am I bringing this up? Since about 2014, I have been saying how Gateways are duplicitous and insecure. Yesterday security vulnerability CVE-2022–31692 was released with a CRITICAL rating which acknowledging that ‘internal redirects’(ie forwards) are not addressed in Spring Security and this has existed for the last few YEARS.

I will go over how this exact SAME ISSUE affects API gateways and how they have failed to address this.

Understanding the API Call Flow

First, to understand the issue, you must understand how an api call works by understanding the api call flow

After a client calls an API, an API backend can ‘route’ the call to another API endpoint two different ways (both of which are W3C standards supported by ALL app servers):

redirect — A redirect allows you to make a 3rd party call. They can also be used to call another api endpoint via a ‘round robin’; a thread is dropped, the call goes outside the DMZ, comes back in via the router/proxy, the request/response are reissued and a new thread is created (see diagram below)

CORRECTION: Redirect should show as a ‘RESPONSE’, not ‘REQUEST’… as a new ‘request/response’ is issued at the proxy/gateway — Correction: REDIRECT should show as ‘RESPONSE’ (not ‘REQUEST) as new request/response is issued at proxy/gateway

internal redirect (aka forward) — an ‘internal redirect’ is strictly internal and does NOT leave the application environment. As a result, this can be 200+% FASTER than a redirect. It does this by using the front controller in the MVC application to reroute the request/response to another endpoint within the application .

Can My Language/Platform/Tool Do This???

Internal redirects exist in EVERY framework that handles the HTTP protocol and if you are handling CORS, you are definitely doing this! Just about every tool and language does this as ‘internal redirects’ (aka forwards) and are FASTER and have less latency than redirects and are a standard part of the W3C standard; an ‘internal redirect’ is just a REDIRECT that gets routed INTERNALLY by a Front Controller.

What is a Front Controller?

In EVERY MVC Framework/tool, the‘front controller’ is a class/service that handles the routing for the Model/view/controller (see diagrams above).

When a request comes in, this is what tell the request how to call the controller/api endpoint.

‘Internal Redirects’ use the existing request to REDIRECT back to the front controller and then ROUTE to another endpoint INTERNALLY. This is 100% safe and secure because you can use the existing user token (sent with the original request) to check against all other endpoints.

So what is The Problem?

The problem as you see above is that an ‘internal redirect’ only works within the constrains of the application. However, a proxy/gateway REQUIRES a REDIRECT for its security checks to be done!

So if you have abstracted ALL SECURITY to an API Gateway, all security checks for the other endpoint that we are INTERNALLY REDIRECTING to will never be done!!

This has been a known issue for gateways for YEARS but they do not make it known to end users as they have a product to sell.

Rather than admitting they can’t handle ALL traffic for your API’s, they will tell you:

‘don’t do that’ : some vendors have taken to saying don’t use ‘forwards’ (which are far faster and more scalable). First, this is unacceptible as you need them for security like CORS. Secondly, this is a W3C Standard (which they are supposed to support OUT OF THE BOX). And thirdly, this is an INSANE answer because you want to have your application be more scalable; even if you are horizontally scaling, vertical scale will save you thousands and make your response time far better. REDIRECTS create latency and FORWARDS reduce latency!
‘duplicate our security in your app’ : the other response when this is pointed out is to duplicate all security in your app. The question here though is: once you DUPLICATE securty in your API backend, what’s the point of an API Gateway? A load balancer is all thats needed at that pointy … making the API Gateway redundant and useless

As you can see, this vulnerability undermines the entire business model of the API Gateway and makes them obsolete… because you can either :

have speed/scale by reducing your I/O overhead and latency of using REDIRECTS and switch to using ‘internal redirects’ or…
you can use an API Gateway and REQUIRE redirects for EVERY INTERNAL API CALLBACK and thus slow down ALL your API calls and traffic and increase your chances of MITM attacks.

Vendor Responses

Since this article originally came out at the beginning of Oct,2022, we have had a great response and 60% read rate… but vendors are not as big of fans

Tyk.io : The founder has headed down a ‘personal’ path of denial. Hitting the 5 stages of grief : ‘denying’ the issue exists, ‘anger’ at having it pointed out by a professional with 8 yrs of experience, ‘bargaining’ by saying everyone uses it thus flaws can’t exist. With luck, he will soon hit ‘depression/acceptance’

AWS : Even though I have consulted the AWS Lambda team on this and other issues, they give a slight nod to this issue by stating:

While this synchronous flow may work within a single application on a server, it introduces several avoidable problems in a distributed serverless architecture

Amazons example shows a ‘slanted worst case scenario’ that one would never do (and would quickly realize how untenable it is). But at least they acknowledge that they can’t deal with an api calling another api.

Kong/Postman : I had a nice conversation with a product manager at Kong (who now works for Postman), who was so ill-informed that they were convinced that the ‘front controller’ was a Java specific pattern :

Complete lack of education in API call flow like this is very common and I have had conversations like this with Netflix, AWS and VMWare (but not so rude) where they are unaware of HTTP call flow and basic pattern used to implement API pattern.

Calling Apis From Apis

Gateways like vendors are keenly aware of this issue and do not have a solution as they have effectively painted themselves into a corner.

This problem stems from being able to call API’s from other API’s which you can read about more fully in our next article…

(continue to Why Api Gateways Are Dead part 2)