APIs are everywhere, and their security is becoming challenging.
Gartner is seeing explosive growth of APIs and estimates that by 2025 less than 50% of enterprise APIs will be managed; the companies just don’t have the capacity to do it. So, API security is becoming a crucial topic.
It goes without saying that APIs are deployed everywhere. For instance, a website click quickly initiates a dozen REST calls directly from your browser and another dozen behind the scenes. Software engineers like you integrate with APIs more and more to develop new features and enhancements.
Are you able to secure your company’s API sprawl?
As software engineers, we can divide APIs into two kinds: those we build & maintain ourselves (the homegrown); and those we consume (the 3rd-party externals). In this webinar, TeejLab Founder & CEO Dr. Baljeet Malhotra and Julius Musseau talked about API risks, API governance, and best practices for software engineers building and consuming APIs.
Why Do APIs Matter?
- The “REST Revolution” gave us all an important software architecture for free: front-end/back-end.
- And then back-ends started calling back-ends.
- And the rest is history!
What do we need to do?
APIs act as translators that allow communication between various devices and/or apps. APIs must be: Discovered, secured, and governed systematically.
API Proliferation
The overall ecosystem of APIs at the global scale is already into millions of public APIs. We have indexed a lot of them that way, and we have built the world’s largest repository of APIs, more than what programmable web has, more than what rapid API has, or even that other organizations may have catalogued.
For example:
- Microsoft in 2020: 60,000
- Google: 35,000
- Amazon: 30,000
How do you discover APIs?
It is a technologically challenging problem. It is a very easy concept to understand but very hard to solve because the information over the internet could be so unstructured.
There is a lot of unstructured information available on the internet, and a lot of this information is embedded in the software liability itself because a lot of times, a lot of companies have APIs, but they never published a report or a portal or a page which describes their APIs simply because either they don’t have a business functionality, they want to expose, or they just want to keep these APIs secrets for just their customers and partners.
There are various mechanisms we are applying that are curating this information at a global scale, mining repositories mining international web pages.
It is possible to get visibility into authenticated APIs?
Yes, because if you just see the declaration of an endpoint that isn’t good enough, that doesn’t tell you what that API actually does. So, if we wanted to go beyond that, we need to authenticate and access the API, and many times you need to register to get the account, get the API keys, or in some cases, the authentication can be author or JWT.
So we could use these APIs as much as we could, but there’s a lot of automation that can’t be done because you actually have to register to get the key.
And to do that, we need to have information where we can actually authenticate and make a call to the API and actually see what data comes in and out, look at the header, look at the response and other information so that there are authenticated APIs in your index absolutely no interest, that’s what makes things more interesting.
How can you secure public APIs?
Simple things, for example, you may create an account to access an API, do some experimentation and may end up not using it, but it can stay there; you may forget maybe you might hardcore the password because you were in an experimental shooting mode and suddenly you checked out this library and somebody decided to make this open source. There you go, you expose some of those things.
The first step is to be aware of all your APIs, document them, and nicely catalogue them. Because the problem is a lot of times, teams do not know their APIs and end up being exposed to unnecessary risks.
How can you secure internal APIs?
The typical approach taken is since this is an internal API, you don’t need to authenticate; you don’t need the layer that is needed for my publicly exposed API. So, actually, the zero trust principle is authentication. Authorization is a must for all your resources. If you’re treating your API as a resource, then you want to make sure that you are using the same level of authentication authorization tightness around your internal APIs as much as you’re doing for your external APIs.
Advice for building brand-new APIs
As we know, security doesn’t start when your product is built, and then you buy the best tool to fix your problem; that’s not how it should be security. It starts with your design, and security starts with your stakeholders.
For example, if you’re building API, ask the very first question who are we building this for? Who needs to consume it? Is this an API that only one set of customers needs to use, or is this a very useful API that perhaps hundreds and thousands of users need to consume it? Is this a paid API? Is this a free API?
All this is part of your security assessment which starts with the design aspect itself, and then, what’s the best way for us to authenticate it?
If there is an API that needs to be doing machine-to-machine communication, you don’t want to implement OAuth or token-based because it defeats the purpose of machine-to-machine communication. Maybe an API key base, but what is the session approach you want to take? How far will your tokens go on to be?
So all starts with the design thinking in place and making sure that you understand your stakeholder, the user and what is the criticality they are going to support. Once you have figured out those details, you can start to implement, test and ongoing monitoring them.
