APIs, APIs Everywhere!

Numerous (and by that, I mean all of them) mobile and cloud-native applications are based on APIs. They’re everywhere! If one app has a connection to another app or business, it’s almost guaranteed to use an API.

In addition to securing individual applications, organizations are increasingly turning to API gateways to unify the management of multiple applications across an organization.

There’s no question that an API gateway is essential for securing applications and the users who interact with them and is part and parcel of modern application architecture.

It’s a single point of entry for client applications to access backend services, providing a convenient and secure way to manage and monitor access to these services. Implementing proper and reasonable security measures in the API gateway further ensures that only authorized clients can access the backend services, reducing the risk of data breaches and other security incidents.

Being the entry point and control mechanism for vital services and information, API gateways are the target of various types of attacks, such as DDoS (distributed denial of service), to disrupt public access to the services. Attackers also exploit vulnerabilities in the API gateway to gain unauthorized access to the backend services. The API gateway must be able to handle high volumes of requests without becoming a bottleneck or a single point of failure. This requires implementing scalability and resiliency measures, including load balancing and failover mechanisms.

API Gateway Benefits

Some API gateway benefits are:

• They can handle authentication, logging, and monitoring
• They are resilient
• Clients can access the necessary data as needed.
• Their protocol flexibility provides the ability for disparate clients and microservices to communicate.

We are now getting out of all an API gateway can do and into what it cannot do. Are they necessary? Yes. Are they an all-in-one solution? No.

API Gateway Limitations

Some limitations to API gateways are:

• Possible performance degradation due to increased resource usage
• A single point of entry means a single point of failure
• Whether using one gateway or many, the administrative overhead is increased. More gateways to deploy to prevent a single point of failure means even more administration.
• If an org can’t handle the current amount of detail, additional detail is unhelpful.
• The gateway adds an additional network hop in the API call.
• Too much logic implementation in the gateway leads to dependency issues.

Important note: the term “API Gateway” is like many other solutions – current terms may only reference what many are familiar with while also applying numerous technologies underneath. Take “antivirus” as an example. I can’t think of anything that is “antivirus.” It’s antivirus, antimalware, ad blocker, endpoint protection, and several other technologies wrapped in the acronym AV. So new gateways will often have many different security controls built in. And even with that, proper AppSec requires more than just one appliance or solution. When perusing solutions, caveat emptor.

What does it have in common?

Part of API security is like any other security – it requires actions common to all. Here are just a couple.

Inventory

Its spot within the first two CIS Controls demonstrates the importance of inventory and control of enterprise and software assets. If you don’t know what you have, you don’t know what needs to be protected. Like any other technology, APIs must be updated, modified, deprecated, etc., as required.

Details, details, details

So much of application security is details – keeping track of what’s new, what needs to be replaced and when, what gets upgraded, who no longer needs access, etc. There are lots of exploratory and innovative things to do in appsec, but an indelible mark is that there are tons of details to monitor.

What’s Different?

Part of API security is unlike others because APIs are different from other web technologies. How different? Different enough that A) in 2021, Gartner made API its own category separate from other web technologies, and B) OWASP has its own OWASP API Top 10.

Some of the vulnerabilities inherent to APIs are:

• Broken Object Level Authorization (BOLA)
• Sensitive Data Exposure, and
• Security Misconfiguration

What’s (somewhat) new?

A third aspect is particular to APIs but is similar to the first general approach and involves a layered security, or defense-in-depth, approach. But this is different because the layers are API-specific. The nature of APIs (at least the public ones) makes them open to abuse by anybody because they’re designed to be accessed.

Here are a couple of examples:

• Rate limiting is a must, but it’s different from typical website rate limiting because the endpoints that access the API may very well be allowed to access it at the rate of X times/second.
• If the rate is too fast, attackers can abuse the API by going slowly. So, determining the drip or low-and-slow attacks is just as crucial as blocking too many-too fast attempts.

The defense-in-depth comes into play here because the different layers must be API-specific, but not a single point of failure, while remaining monitored and being updated – all at the same time.

Runtime protection is one of the layered aspects: It should also detect behavior anomalies such as credential stuffing, brute forcing, or scraping attempts. According to a recent report, not adequately addressing runtime security was among the top API concerns by respondents.

Gartner reports that “…no single application security innovation can deliver comprehensive security”.

The various components must allow the right people to access the right resources and get the correct information. Still, they must also ensure that API attacks are detected, and alerts are attended to immediately.

It’s complicated

Application design and deployment, API architecture, application security – it’s all complicated. That’s not news, but it still needs to be shouted from the rooftops. Like is said of the duck, it’s moving smoothly on the surface, but underneath there’s a whole lot of paddling going on. APIs can be easy to deploy, and securing them may seem straightforward, but it’s not that simple.

Keep an eye on things, do your due diligence, and you’ll find the right solutions to defend your data.

About the Author: Ross Moore is the Cyber Security Support Analyst with Passageways. He was Co-lead on SOC 2 Type 1 implementation and Lead on SOC 2 Type 2 implementation, facilitated the company’s BCP/DR TTX, and is a HIPAA Security Officer. Over the course of his 20 year IT career, Ross has served in a variety of operations and infosec roles for companies in the manufacturing, healthcare, real estate, business insurance, and technology sectors. He holds (ISC)2’s SSCP and CompTIA’s Security + certifications, a B.S. in Cyber Security and Information Assurance from WGU, and a B.A. in Bible/Counseling from Johnson University. He is also a regular writer at Bora.