The 4 Biggest API Tooling Issues in Last Decade (and why they still exist)

Modern ‘shake-n-bake’ developers being cranked out of ‘code camps’ do not understand the fundamentals of how an API backend works (much less how to build and secure one). And taking the time to learn requires more of an attention span than a 128 character tweet.

Tools have been built to support this new generation of lazy developers who either don’t want to/can’t understand API backends.

In this article, we break down the biggest issues in API tooloing in the last decade.

API As Service (AKA ‘AWS LAMBDAS’)

Like a hand me down sweater your aunt knitted, one size does NOT FIT ALL. But don’t tell the AWS team that.

When they asked me to consult with them on LAMBDAS (and their API Gateway), I pointed out several flaws and they admitted that it doesn’t scale. BUT… the cloud can scale and thats how they CHARGE YOU to get the service to scale!

This is the ‘Ruby phenomenon’ : Twitter used to use RUBY for their servers and would horizontally scale much like Lambdas. But the cost was EXCORBANT. Unfortunately, they couldn’t pass the cost on to a customer like AWS does… so they realized they had to improve the application.

On avg, a single LAMBDA instance will do 60–80/rps:

Note that this is in STARK contrast to an single instance API backend with security build by a professional:

And as a result, this has bankrupted some people.

API Gateways

Another issue is security. No one wants to deal with this (or learn it) so they just purchase a tool… like a Gateway product.

This is a scam. Always has been. And this is the hackers best friend when it comes to api’s.

Why? Because of a simple W3C standard that is commonly called a FORWARD in the Java world (but exists in EVERY web server).

A ‘forward’ is an internal redirect (unlike a ‘redirect’ which drops a thread, goes outside the DMZ, comes back in and recreates the request/response). Thus it is faster and more secure.

It also BYPASSES ALL SECURITY at the gateway. However it is a standard so it must be supported. Thus implementors of Gateways have known for years that they are creating an insecure tool but have pushed it down peoples throats.

Redirects

Redirects have become a standard in nearly every tool and are another hackers best friend.

Every time a Redirect happens, you:

• drop a thread
• leave your network and come back in
• reissue a thread
• reissue the request/response

This leave you wide open to MITM attacks for every redirect you do.

It also makes your API’s EXTREMELY slow.

GRAPHQL uses redirects for stitching and will issue DOZENS of redirects when stitching ‘queries’.

Lack of Security

Even when you think you are handling everything with tokens, cors, and user roles, most people completely ignore things like OWASP API top ten to better secure your input/output and endpoints.

They just assume that their tools will take care of it and thats that. There is not additional thought.

In Closing

API development is a job. It is not a tool and the companies who hire shake-n-bake developers/architects who just use tools are the ones getting their data hacked every day.

If you want a secure system, hire someone who understand how to implement, scale and secure you companies apis.